This only happens on 32-bit windows. This used to work with dmd 2.064 beta 1 and all previous versions of dmd. The attached repro case does not work with the latest git head of the 2.064 branch (718dfbb02f8ca7356e8f46637b2e90e2f81d96d0).
For building the attached repro case simply run the build.cmd inside the src directory. The script will automatically run libunres on the generated lib file to list all the unresolved symbols. When compiling the attached repro case with dmd 2.064 beta 1 or any version before that you will notice that the symbol "_D6thBase6plugin8ScanPair6__initZ" is not in the list of the unresolved symbols. If you run libunres -p on the generated file you will notice that the symbol actually is part of the public symbols. When compiling with the latest git head dmd the symbol "_D6thBase6plugin8ScanPair6__initZ" will be listed as unresolved symbol and will not be listed when running libunres -p.
Also really interresting about the repro case is, that if you remove the line from build.cmd which adds thBase\container\hashmap.d the library will stop compiling with some strange import error messages.
The repro cases includes the modified druntime import folder of my version of druntime. A possible reason for this issues are the public imports inside object.di which might cause the issue for whatever reason. When removing -version=NOGCSAFE from the build command for the lib the issues goes away. Doing so will disable the public imports inside object.di.
I don't quite understand why this only happens when compiling for 32-bit. It works fine for 64-bit?
Comment #5 by code — 2013-10-21T10:16:34Z
What's your actual problem with the generated library?
I don't can't produce any link errors so the symbol is in the library.
Also libunres shows _D6thBase6plugin8ScanPair6__initZ as common symbol (using -d).
The only strange thing I found is that COMDEF records are not added to the library symbol table (https://github.com/dawgfoto/dmd/compare/fix11280).
It seems like libunres showing an unresolved symbol is a libunres bug.
That said I'm lacking any useful and reliable tool to inspect omf lib symbol tables.
Comment #6 by code — 2013-10-21T10:54:15Z
The actual problem is that optlink also lists _D6thBase6plugin8ScanPair6__initZ as unresolved symbol. Just like libunres. Which results in my application no longer linking with dmd 2.064.
Comment #7 by code — 2013-10-21T11:31:12Z
I can also reproduce the described libunres behavior with a minimal test case.
struct Foo {}
void bar() { Foo[2] foos; } // references Foo.init
Comment #8 by code — 2013-10-21T11:33:38Z
(In reply to comment #6)
> The actual problem is that optlink also lists _D6thBase6plugin8ScanPair6__initZ
> as unresolved symbol.
Mmh, I can't reproduce that.
Comment #9 by code — 2013-10-21T13:06:42Z
You have to add my version of the druntime import folder (which is included in the repro case), specify -version=NOGCSAFE and impor thBase.logging to trigger the bug. I can will add a simple executable which causes the linker error tomorrow. I removed it from the repro case because I thought it is not releveant as libunres also lists the symbol as unresolved.
Comment #10 by code — 2013-10-22T01:18:06Z
Created attachment 1276
repro case with executable
Comment #11 by code — 2013-10-22T01:19:27Z
The second repro case will compile fine using dmd 2.064 beta 1. When using the latest git head of the 2.064 branch it will fail to compile with the optlink error message:
Error 42: Symbol Undefined _D6thBase6plugin8ScanPair6__initZ
I'm using optlink:
OPTLINK (R) for Win32 Release 8.00.13