On 13.10.2015 21:44, ZombineDev wrote:
On Tuesday, 13 October 2015 at 19:17:27 UTC, ZombineDev wrote:
On Tuesday, 13 October 2015 at 19:14:51 UTC, ZombineDev wrote:
[...]

Is the problem related to the new CRT in VS2015? Previously I thought
that the problem is 64-bit only, but it seams like it is for both 32-bit
and 64-bit MSCOFF.

The library issues are the same for 32-bit and 64-bit.


With the VS2015 x64 Native Tools Command Prompt I did:
cl main.cpp C:\D\dmd2\windows\lib64\phobos64.lib

And got:

main.cpp
phobos64.lib(sections_win64_6c9_5a5.obj) : error LNK2019: unresolved
external sy
mbol _minfo_beg referenced in function
_D2rt14sections_win6414getModuleInfosFZAy
PS6object10ModuleInfo
phobos64.lib(sections_win64_6c9_5a5.obj) : error LNK2019: unresolved
external sy
mbol _minfo_end referenced in function
_D2rt14sections_win6414getModuleInfosFZAy
PS6object10ModuleInfo
phobos64.lib(sections_win64_6c3_4e2.obj) : error LNK2019: unresolved
external sy
mbol _deh_beg referenced in function
_D2rt14sections_win6412SectionGroup8ehTable
sMxFNdZAyS2rt15deh_win64_posix9FuncTable
phobos64.lib(sections_win64_6c3_4e2.obj) : error LNK2019: unresolved
external sy
mbol _deh_end referenced in function
_D2rt14sections_win6412SectionGroup8ehTable
sMxFNdZAyS2rt15deh_win64_posix9FuncTable
phobos64.lib(config_48f_452.obj) : error LNK2019: unresolved external
symbol snp
rintf referenced in function
_D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
phobos64.lib(config_48f_452.obj) : error LNK2019: unresolved external
symbol ssc
anf referenced in function
_D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
main.exe : fatal error LNK1120: 6 unresolved externals

AFAIR, the support for VS2015 CRT was merged and is included in this
release, correct?

Yes, but there is some magic involved when linking against the VS2015 CRT. To use symbols like snprintf and sscanf, you must also pass legacy_stdio_definitions.lib to the linker, which is done automatically if you use dmd as a frontend to the linker, but not cl.

Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only emitted by the compiler if you compile main, WinMain or DllMain. Unfortunately, compiling D's main also generates a C-style main, so it's not so easy to get these symbols if you need main in C/C++.

I would currently recommend to write main in D, and call into C/C++ from there.

Reply via email to