`ar` archiver issue

[raysan5]

When using w64devkit ar tool, I got a popup about an errors on libdep.a. The popup appears twice and after accepting it both times the library is correctly archived and works on further compilations with no error. It happens with both i686 and x86_64 versions.

Environment:

  CPU: Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz
  RAM: 8 GB
  OS: Windows 10 Pro 64bit (21H1, 19043.1165)

  Command line: 
    C:\raylib\w64devkit\bin\ar.exe rcs libraylib.a rcore.o rglfw.o rshapes.o rtextures.o rtext.o rmodels.o raudio.o utils.o

I'll try on a second computer to see if it happens the same.

[raysan5]

More info. I took a quick look to libdep.a and this is what I got:

C:\raylib\w64devkit\bin>objdump -a ../lib/bfd-plugins/libdep.a
In archive ../lib/bfd-plugins/libdep.a:

libdep_plugin.o:     file format pe-i386
rw-r--r-- 0/0   3564 Sep 18 02:48 2021 libdep_plugin.o

C:\raylib\w64devkit\bin>objdump -f ../lib/bfd-plugins/libdep.a
In archive ../lib/bfd-plugins/libdep.a:

libdep_plugin.o:     file format pe-i386
architecture: i386, flags 0x00000039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000

C:\raylib\w64devkit\bin>nm -gD ../lib/bfd-plugins/libdep.a

libdep_plugin.o:
nm: libdep_plugin.o: no symbols

C:\raylib\w64devkit\bin>nm -g ../lib/bfd-plugins/libdep.a

libdep_plugin.o:
         U __imp__isspace
         U _fflush
         U _free
         U _lseek64
         U _malloc
         U _memmove
00000484 T _onload
         U _read
         U _strchr
         U _strcmp
         U _strdup
         U _strlen
         U _strncmp
         U _strtoul

When running the nm command, I got the previous popup twice again.

EDIT: I checked my previous MinGW version (MinGW-w64 32bit, GCC 8.2.0) and libdep.a does not exist.

[raysan5]

Ok, after a quick Google of the issue, found it here: https://github.com/msys2/MINGW-packages/issues/7890

EDIT: Removing w64devkit/lib/bfd-plugins directory and the libdep.a file solves the issue... I love computers...

[skeeto]

Curiously I could only reproduce the issue when Binutils binaries are run directly from cmd.exe, which is why I've never seen this (I always use BusyBox). It's unclear to me why the environment would change the behavior.

Since libdep is a plugin, "libdep.a" is always wrong. At best it's useless, and in this case it's causing malfunction when Binutils tries to LoadLibrary it (hence the popup error from Windows rather than an error printout from Binutils). The popup message is a symptom of a bad build rather than the problem in itself.

I could delete it from the plugins directory after installation (to the prefix) and go without. However, it seems there's no reason to use the Binutils configuration options --enable-static and --disable-shared anyway. These options are probably just broken and were never intended to be used. Instead I probably want --with-static-standard-libraries. I'll switch over and check that it works as intended.

[raysan5]

@skeeto Thanks for the detailed explanation! For now, just removing it does the trick. Afaik it does not affect any other tool.