Bug 17707 – unimported modules in libraries do not have their module constructors run

First with object files: % ls app.d foo.d % cat app.d void main() { import core.stdc.stdio; puts("and from here"); } % cat foo.d static this() { import core.stdc.stdio; puts("hello"); } % dmd -c app.d foo.d % ls app.d app.o foo.d foo.o % gcc app.o foo.o -lphobos2 % ./a.out hello and from here Everything looks fine there % ar rcs foo.a foo.o % gcc app.o foo.a -lphobos2 % ./a.out and from here the module constructor from foo.d has gone missing! test on macOS and linux, with many different permutations. Splitting the object file back out of the library makes it work again, so no information is lost. On macOS it was easy to discover that the result of getsectbynamefromheader_64 for __DATA __minfodata is missing an entry for foo in the library case, but not in the object case.

The same behaviour is observed when the library is made with dmd, when the linking is done with dmd, etc... Essentially dmd seems to be doing something different with the __modctor it gets from an object file or a library

This is the expected behavior of static libraries. The linker is eliding object files that are contained within a static library when it sees that the object file has no references to it. This behavior also exists on Windows.

Yep, this is expected default behavior. But linkers support force-pulling all object files from static libs: * ld: --whole-archive libfoo.a --no-whole-archive * Apple ld64: -force_load libfoo.a * MS link.exe: /WHOLEARCHIVE:foo.lib