Beta D 2.069.0-b1

Rainer Schuetze via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Wed Oct 14 05:39:45 PDT 2015



On 14.10.2015 13:46, ZombineDev wrote:
> 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)

Your C++ project should have the library paths setup correctly to find 
it if you just add it to the additional input libraries.


> 2) How can I workaround the problem that _minfo* and _deh* are not
> generated because my main is in C++?
>

As Szymon noticed, you can compile an empty main into the static D 
library. The additional C main that is generated by DMD won't cause 
ambiguities as long as your C main is not also in a static library.


More information about the Digitalmars-d-announce mailing list