www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - cairo(D) / x64 / unresolved externals / don't know why

reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
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
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
next sibling parent Luis <luis.panadero gmail.com> writes:
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
prev sibling parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
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
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 11.01.2016 um 18:27 schrieb Robert M. Münch:
 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.
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 Thaut
Jan 11