when compiling with -O -release -inline -noboundscheck, the following program: import std.stdio; uint[] meuh(){ File f; uint[] vfield=new uint[](3); return f.rawRead(vfield); } void main(){} gives the following error : Error 42: Symbol Undefined _D3std9exception133__T12errnoEnforceTbVAyaa50_433a5c 445c646d64325c77696e646f77735c62696e5c2e2e5c1079E2AF018CEE885E4194B2927ACD6F --- errorlevel 1 This also failes to compile with optimization flags on ldmd2 . It is possible to use '-allinst' to make it compile on dmd. Not that this does compile without optimization flags, and it does compile on linux
it's possible to remove the linker errors by adding std/exception.d to the to-compile file list but then the program immediatly runs out of memory, even though it doesn't when you don't optimize it.
commenting out the line with errnoEnforce in std/stdio.d fixes my problems (but probably breaks a few things). It's not worthy of a patch but it's good enough for me.
I get the same issue on linux with dmd git head. The -inline flag causes the issue for me. I can add -O -release and -noboundscheck without getting the linker issue.
I got that bug, too. I have a small family of examples here. -----example1.d:OK----- import std.stdio; void main () { ubyte [256] buf; stdin.rawRead (buf); } ----- -----example2.d:Fails with -inline----- import std.stdio; void main () { ushort [256] buf; // same with uint stdin.rawRead (buf); } ----- Checked with DMD 2.064.2, DMD 2.065.0 and DMD 2.066-0-b6, the results are roughly the same. Example 1 is OK. In example 2, certain optimizations lead to linker errors. To compile successfully, just run "dmd <file>.d". For versions 2.064 and 2.066, just adding "-inline" causes a linker error. For 2.065, the error requires the full "-release -inline -noboundscheck" to be reproduced locally. -----With "-m32" (OPTLINK):----- OPTLINK (R) for Win32 Release 8.00.15 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html example2.obj(example2) Error 42: Symbol Undefined _D3std9exception140__T12errnoEnforceTbVAyaa53_433a5c546f6f6c735c646d645c77696e646f77735c62696e5cE611F934D2BE6B410FCD651C953DEFB1 --- errorlevel 1 ----- -----With "-m64" (MS VS 12.0 linker):----- example2.obj : error LNK2019: unresolved external symbol _D3std9exception140__T12errnoEnforceTbVAyaa53_433a5c546f6f6c735c646d645c77696e646f77735c62696e5c2e2e5c2e2e5c7372635c70686f626f735c7374645c737464696f2e64Vmi717Z12errnoEnforceFNfbLAyaZb referenced in function _D3std5stdio4File14__T7rawReadTtZ7rawReadMFAtZAt example2.exe : fatal error LNK1120: 1 unresolved externals --- errorlevel 1120 -----
Created attachment 1372 [details] example 1: OK
Created attachment 1373 [details] example 2: fails with -inline
*** Issue 13898 has been marked as a duplicate of this issue. ***
*** Issue 14043 has been marked as a duplicate of this issue. ***
Any news on this one? I think I'm seeing something similar in my code, but it's too much code to pin-point an excerpt and post here.
can't confirm on GNU/Linux x86, dmd git head, commit b9c8ded6
ah… i missed "hardware" section for the bug. sorry for the noise.
Ketmar: we get this on linux too. Specifically, see https://issues.dlang.org/show_bug.cgi?id=14043
yes, but this seems to be x86_64 issue, and i checked it on x86. so i confirmed the thing that is not needed to be confirmed. ;-)
*** Issue 14202 has been marked as a duplicate of this issue. ***
I'm not able to reproduce this with 2.067.0-b2.
(In reply to briancschott from comment #15) > I'm not able to reproduce this with 2.067.0-b2. Had the same bug and switching to 2.067.0-b2 also fixed it. See http://forum.dlang.org/thread/vuyznzmdhuxsefeepegu@forum.dlang.org
(In reply to joeyemmons from comment #16) > (In reply to briancschott from comment #15) > > I'm not able to reproduce this with 2.067.0-b2. > > Had the same bug and switching to 2.067.0-b2 also fixed it. > See http://forum.dlang.org/thread/vuyznzmdhuxsefeepegu@forum.dlang.org I'll mark it as WORKSFORME then.