On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze wrote:
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.

Thanks for the answer.

Just for the reference, under VS2015 x86 Native Tools Command Prompt I tried to link a C++ main function that only calls rt_init() and rt_term() like this:

cl main.cpp C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\legacy_stdio_definitions.lib"

I got:
main.cpp
phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: unresolved external symbol __minfo_beg referenced in function _D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: unresolved external symbol __minfo_end referenced in function _D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo
main.exe : fatal error LNK1120: 2 unresolved externals

Which, based on your answer, is expected.

I'm looking into integrating D into an existing C++ build and I need to statically link the D library. So my next questions are:
1) Where can I find legacy_stdio_definitions.lib?
P.S.: It's included in VS (C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\legacy_stdio_definitions.lib) 2) How can I workaround the problem that _minfo* and _deh* are not generated because my main is in C++?

Basically what's preventing me from using D main is that one of the C++ libraries I use creates threads and dispatches functions to run on them in manner similar to Boost ASIO, and I don't have control over this proprietary library.

To me, the fact that consuming D libraries from C++ works on Linux, but not on Windows seems like a very serious issue with Windows support.

I know that this is work in progress and that VS 2015 broke the ABI of its CRT, and it's hard to track down those problems with every VS release, so let me know if I can help with anything. Currently I do not have enough knowledge tackle the problem, but I am willing to learn.

Reply via email to