Surprised by behaviour of ld --whole-archive
Keith Marshall
kdmarsha111953@gmail.com
Wed Feb 8 19:35:00 GMT 2017
In general, it works just fine, but I was surprised by this case:
$ mingw32-gcc -shared -o libmingwex-0.dll -Wl,--whole-archive \
libmingwex.a -Wl,--no-whole-archive -L.
It appears to have worked successfully, and:
$ nm -A libmingwex.a | less -FX
libmingwex.a:isblank.o:00000000 b .bss
libmingwex.a:isblank.o:00000000 d .data
.
.
libmingwex.a:isblank.o:00000000 T _isblank
libmingwex.a:isblank.o: U __isctype
.
.
shows expected object content in the generated DLL, but:
$ pexports libmingwex-0.dll | less -FX
LIBRARY libmingwex-0.dll
EXPORTS
shows nothing beyond this; the exports table is unpopulated!
FWIW, none of the symbols in static library libmingwex.a are adorned
with the dllexport attribute, so I would have expected all symbols to
be exported by default; what is unusual, in this case, is that static
library -lmingwex is one of those specified by default, by the GCC
driver, when linking mingw32 executable or DLL code, so it will be
scanned a second time, in the --no-whole-archive phase of linking.
This may be intentional behaviour, but I do find it surprising; I
would have expected, particularly considering the nominally single
pass linking behaviour of ld, that the exports table would have been
constructed, along with the object file content, when libmingwex.a
is first read, in the --whole-archive phase of linking.
This is not a major problem; I can work around it:
$ ln -s libmingwex.a mingwex.lib
$ mingw32-gcc -shared -o libmingwex-0.dll -Wl,--whole-archive \
mingwex.lib -Wl,--no-whole-archive -L.
$ pexports libmingwex-0.dll | less -FX
LIBRARY libmingwex-0.dll
EXPORTS
_Exit
__Balloc_D2A
__Bfree_D2A
.
.
which shows expected content in the exports table, in addition to
the DLL object content. However, given that it took me by surprise,
I thought it worth mentioning.
--
Regards,
Keith.
More information about the Binutils
mailing list