digitalmars.D.learn - cairo(D) / x64 / unresolved externals / don't know why
- =?iso-8859-1?Q?Robert_M._M=FCnch?= (29/29) Jan 10 2016 I made to compile a bunch of libs on Win64 and got my D project
- Benjamin Thaut (15/31) Jan 10 2016 You should not need to link manually against msvcrt, dmd does
- Luis (4/6) Jan 11 2016 I saw VisualD (dub generated project file) doing that with the
- =?iso-8859-1?Q?Robert_M._M=FCnch?= (14/26) Jan 11 2016 Great, thanks for this.
- Benjamin Thaut (12/14) Jan 11 2016 This seems to be a general convetion on windows. All c++ compilers I've
I made to compile a bunch of libs on Win64 and got my D project compiled as well. Only problem left are some strange unresolved externals. Linking... dmd -of.dub\build\application-debug-windows-x86_64-dmd_2069-F0A1450B9B033D5CD11F3F60 81557B0\webchat.exe .dub\build\application-debug-windows-x86_64-dmd_2069-F0A1450B9B033D5CD11F3F60 81557B0\webchat.obj ..\vibe-d-0.7.26\lib\win-amd64\libeay32.lib ..\vibe-d-0.7.26\lib\win-amd64\ssleay32.lib ..\cairoD\cairoD.lib C:\Users\robby\AppData\Roaming\dub\packages\derelict-ft-1.0. \lib\DerelictFT.lib C:\Users\robby\AppData\Roaming\dub\packages\derelict-util-2.0.4\ ib\DerelictUtil.lib C:\Users\robby\AppData\Roaming\dub\packages\x11-1.0.9\x11.lib ..\vibe-d-0.7.26\vibe-d.lib wsock32.lib ws2_32.lib advapi32.lib user32.lib -LD:\develop\cairo\cairo\src\release\cairo-static.lib -LD:\develop\cairo\libpng\libpng.lib -Lgdi32.lib -m64 -m64 -m64 -m64 -m64 -m64 -g cairo-static.lib(cairo-image-source.obj) : error LNK2001: unresolved external "__imp__hypot" and some more missing in other .obj files: "__imp__ctime64" "__imp_ldiv" "__imp_strncpy" "__imp_rand" IMO this all looks like msvcrt standard lib stuff so wondering why it's not found. Do I explicitly have to link to the msvcrt lib? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Jan 10 2016
On Sunday, 10 January 2016 at 22:22:03 UTC, Robert M. Münch wrote:I made to compile a bunch of libs on Win64 and got my D project compiled as well. Only problem left are some strange unresolved externals. Linking... dmd -of.dub\build\application-debug-windows-x86_64-dmd_2069-F0A1450B9B033D5CD11F3F60 81557B0\webchat.exe .dub\build\application-debug-windows-x86_64-dmd_2069-F0A1450B9B033D5CD11F3F60 81557B0\webchat.obj ..\vibe-d-0.7.26\lib\win-amd64\libeay32.lib ..\vibe-d-0.7.26\lib\win-amd64\ssleay32.lib ..\cairoD\cairoD.lib C:\Users\robby\AppData\Roaming\dub\packages\derelict-ft-1.0. \lib\DerelictFT.lib C:\Users\robby\AppData\Roaming\dub\packages\derelict-util-2.0.4\ ib\DerelictUtil.lib C:\Users\robby\AppData\Roaming\dub\packag s\x11-1.0.9\x11.lib ..\vibe-d-0.7.26\vibe-d.lib wsock32.lib ws2_32.lib advapi32.lib user32.lib -LD:\develop\cairo\cairo\src\release\cairo-static.lib -LD:\develop\cairo\libpng\libpng.lib -Lgdi32.lib -m64 -m64 -m64 -m64 -m64 -m64 -g cairo-static.lib(cairo-image-source.obj) : error LNK2001: unresolved external "__imp__hypot" and some more missing in other .obj files: "__imp__ctime64" "__imp_ldiv" "__imp_strncpy" "__imp_rand" IMO this all looks like msvcrt standard lib stuff so wondering why it's not found. Do I explicitly have to link to the msvcrt lib?You should not need to link manually against msvcrt, dmd does this for you. You can view the linker commands that are stored inside a object file via microsoft dumpbin tool "dumpbin /DIRECTIVES your.obj". You should check the declarations of the functions that cause a unresolved external error. If they have a "export" in front of them, remove the export. I can not think of any other reason why dmd would otherwise reference a import symbol. Import symbols are symbols used for dll linking and start with "__imp_" Out of curiosity, why do you pass "-m64" 6 times to dmd? Once would be enough. For debug builds targeting windows 64 I would also highly recommend using "-gc -op" instead of "-g". This will give a much better debugging experience in Visual Studio.
Jan 10 2016
Luis <luis.panadero gmail.com> On Monday, 11 January 2016 at 06:53:51 UTC, Benjamin Thaut wrote:Out of curiosity, why do you pass "-m64" 6 times to dmd? Once would be enough.I saw VisualD (dub generated project file) doing that with the latest version of Visual Studio comunnity, when I change to 64 bit building.
Jan 11 2016
On 2016-01-11 06:53:51 +0000, Benjamin Thaut said:You should not need to link manually against msvcrt, dmd does this for you.Ok, that was what I expected.You can view the linker commands that are stored inside a object file via microsoft dumpbin tool "dumpbin /DIRECTIVES your.obj".Great, thanks for this.You should check the declarations of the functions that cause a unresolved external error. If they have a "export" in front of them, remove the export. I can not think of any other reason why dmd would otherwise reference a import symbol.Ah, good point. I didn't see the link to the DLL import stuff. I can't / shouldn't remove them because these are coming from <math.h> It looks like my project is mixing up static and dynamic linked runtime libs.Import symbols are symbols used for dll linking and start with "__imp_"Is this a DMD convention or a general one? Never heard about this.Out of curiosity, why do you pass "-m64" 6 times to dmd? Once would be enough.I don't have a clue where these come from. I just use DUB to compile my D project.For debug builds targeting windows 64 I would also highly recommend using "-gc -op" instead of "-g". This will give a much better debugging experience in Visual Studio.Ok, will see how to get this in. Thanks so far for all the hints. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Jan 11 2016
Am 11.01.2016 um 18:27 schrieb Robert M. Münch:This seems to be a general convetion on windows. All c++ compilers I've seen on windows so far emit so called import symbols using the "__imp_" prefix. Basically its just another level of indirection during a function call to be able to resolve function addresses at runtime, e.g. implement dynamic linking. Its kind of a implementation detail, so in theory you don't have to know about it. But it helps when reading linker errors. In case my talk gets accepted for dconf 2016 I'm going to cover this there in more detail. -- Kind Regards Benjamin ThautImport symbols are symbols used for dll linking and start with "__imp_"Is this a DMD convention or a general one? Never heard about this.
Jan 11 2016