[Issue 11280] New: [REG 2.064] Symbol missing although it should be there

http://d.puremagic.com/issues/show_bug.cgi?id=11280

           Summary: [REG 2.064] Symbol missing although it should be there
           Product: D
           Version: D2
          Platform: x86
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: code@benjamin-thaut.de


--- Comment #0 from Benjamin Thaut <code@benjamin-thaut.de> 2013-10-16 03:23:34 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11280 --- Comment #1 from Benjamin Thaut <code@benjamin-thaut.de> 2013-10-16 03:23:59 PDT --- Created an attachment (id=1267) repro case -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11280 --- Comment #2 from Kenji Hara <k.hara.pg@gmail.com> 2013-10-19 12:24:58 PDT --- Introduced commit: https://github.com/D-Programming-Language/dmd/commit/fc9b88cddaf3a279dcf5ce1ec8b262c4a47020e1 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11280 Walter Bright <bugzilla@digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@digitalmars.com --- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2013-10-20 19:54:46 PDT --- Hmm, pull request 2660. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11280 --- Comment #4 from Benjamin Thaut <code@benjamin-thaut.de> 2013-10-21 05:02:20 PDT --- I don't quite understand why this only happens when compiling for 32-bit. It works fine for 64-bit? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11280 Martin Nowak <code@dawg.eu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |code@dawg.eu --- Comment #5 from Martin Nowak <code@dawg.eu> 2013-10-21 10:16:34 PDT --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11280 --- Comment #6 from Benjamin Thaut <code@benjamin-thaut.de> 2013-10-21 10:54:15 PDT --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11280 --- Comment #7 from Martin Nowak <code@dawg.eu> 2013-10-21 11:31:12 PDT --- I can also reproduce the described libunres behavior with a minimal test case. struct Foo {} void bar() { Foo[2] foos; } // references Foo.init -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11280 --- Comment #8 from Martin Nowak <code@dawg.eu> 2013-10-21 11:33:38 PDT --- (In reply to comment #6) > The actual problem is that optlink also lists _D6thBase6plugin8ScanPair6__initZ as unresolved symbol. Mmh, I can't reproduce that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11280 --- Comment #9 from Benjamin Thaut <code@benjamin-thaut.de> 2013-10-21 13:06:42 PDT --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

Forums