Bug 22 – ModuleInfo not being generated for object files with "dmd -c"

On Linux, attempting to link an object file previously compiled with "dmd -c" generates an error similar to the following: "undefined reference to '_ModuleInfo_...'." Testcases: http://dstress.kuehne.cn/complex/typeinfo_init/a.d http://dstress.kuehne.cn/complex/typeinfo_init/b.d

This issue has arisen in all of my attempts to build libraries on Linux and it was a showstopper until someone discovered that the problem could be avoided by adding a unittest block to problem modules as a way to force ModuleInfo to be created where it wouldn't be otherwise. However, this solution is far from ideal, and it's confusing folks who want to build my library code themselves, as I don't want to make code changes simply to work around what appears to be a code generation problem. Interestingly, Phobos is the only library I've encountered that doesn't exibit this problem, but I've been unable to determine why. However, in my sleuthing today I ran across some code generation differences between Win32 and Linux that may help to shed some light on what's happening. Here are the beginning segments of dmain2 as compiled on Win32 and on Linux for comparison: ---------- Win32 ---------- _TEXT segment dword use32 public 'CODE' ;size is 0 _TEXT ends _DATA segment para use32 public 'DATA' ;size is 148 _DATA ends CONST segment para use32 public 'CONST' ;size is 0 CONST ends _BSS segment para use32 public 'BSS' ;size is 1 _BSS ends FLAT group extrn __d_assert extrn __d_assert_msg extrn __d_array_bounds extrn __d_switch_error extrn _main public _no_catch_exceptions FMB segment dword use32 public 'DATA' ;size is 0 FMB ends FM segment dword use32 public 'DATA' ;size is 4 FM ends FME segment dword use32 public 'DATA' ;size is 0 FME ends extrn ___alloca extrn __except_list extrn __ModuleInfo_3std1c5stdio extrn __nullext wkext __ModuleInfo_3std1c5stdio(__nullext) extrn __ModuleInfo_3std1c6string wkext __ModuleInfo_3std1c6string(__nullext) extrn __ModuleInfo_3std1c6stdlib wkext __ModuleInfo_3std1c6stdlib(__nullext) extrn __ModuleInfo_6object wkext __ModuleInfo_6object(__nullext) ---------- Linux ---------- FLAT group ;File = dmain2.d public _d_assert public _d_assert_msg public _d_array_bounds public _d_switch_error public no_catch_exceptions public main public _ModuleInfo_6dmain2 extrn _Dmodule_ref extrn _ModuleInfo_3std1c5stdio extrn _ModuleInfo_3std1c6string extrn _ModuleInfo_3std1c6stdlib extrn _ModuleInfo_6object I don't entirely understand why the symbols apparently lack a leading underscore in the Linux code, but the real problem seems to be that the Linux code has no equivalent for the OMF wkext blocks which default all ModuleInfo references to __nullext. If my understanding of the object file formats is correct, this suggests that the ModuleInfo blocks are optional in Win32 and are mandatory in Linux. Is this correct? And assuming so, could this be changed? Alternately, I would be very happy if someone could suggest a workaround that doesn't involve code changes.

There seems to be workarounds to this issue, but they are not obvious and not particularly palatable (that is easy and non-intrusive). And the issue is a fantastic timewaster whenever it crops up.

This was apparently fixed a while ago.