cairo(D) / x64 / unresolved externals / don't know why

[Benjamin Thaut via Digitalmars-d-learn]

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-F0A1450B9B033D5CD11F3F60481557B0\webchat.exe .dub\build\application-debug-windows-x86_64-dmd_2069-F0A1450B9B033D5CD11F3F60481557B0\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.2\lib\DerelictFT.lib C:\Users\robby\AppData\Roaming\dub\packages\derelict-util-2.0.4\lib\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?

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.