optlink fails to link an object file compiled with dmd 2.020 with -g or -gc switch.
CL: link test,,,user32+kernel32/co/noi;
Comment #1 by samukha — 2008-10-31T09:13:29Z
Created attachment 277
offending obj
Comment #2 by samukha — 2008-11-13T00:55:10Z
Probably a duplicate of #1439 or/and #424. I suggest voting for #424 as it already has a couple of votes :)
Comment #3 by bugzilla — 2009-02-16T19:35:47Z
I tried linking this obj file, and it linked without complaint, and runs printing "Test".
I suspect the problem may be with multithreading on a multicore system. My system is single core. If you're running multicore, is there a way to use only one core and try it that way?
Comment #4 by samukha — 2009-02-17T02:45:51Z
It fails on a single core. Are you sure you specified /co for the linker? It fails only with the CodeView stuff turned on. Please try to link it like this: dmd test.obj -g
Comment #5 by clugdbug — 2010-05-12T12:36:28Z
This is not the same as bug 1439 or bug 424, which have both been fixed.
I can reproduce it by:
> link test.obj /co
(of course it doesn't link, since the runtime library is the wrong version;
but it still crashes).
Comment #6 by bugzilla — 2010-09-01T18:14:17Z
I can duplicate the problem, and I know where in optlink it is failing, but I don't know why.
Comment #7 by samukha — 2010-09-02T01:54:57Z
This test case was created in the days when I was overly enthusiastic about templates, ctfe and stuff. Now I don't have any code that triggers this error. Lowering the severity to normal as nobody else seems to have suffered from this particular bug.
Please open a new bug unless you have a particularly good reason to believe the crash you're seeing is directly tied to the same cause as this bug. Given that this bug is closed, it's almost a certainty that your issue will be overlooked / lost.