Beta D 2.069.0-b1

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



On 14.10.2015 13:39, Szymon Gatner wrote:
> On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze wrote:
>>
>>
>> On 13.10.2015 21:44, ZombineDev wrote:
>>> [...]
>>
>> The library issues are the same for 32-bit and 64-bit.
>>
>>> [...]
>>
>> 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.
>
> I am trying (as with every new release ;)) to link static D library to
> existing C++ project and I am having same issue:
>
> Error    2    error LNK2019: unresolved external symbol _snprintf
> referenced in function
> _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
> C:\Users\Bravo\documents\visual studio
> 2012\Projects\ConsoleApplication1\ConsoleApplication1\phobos32mscoff.lib(config_48f_452.obj)
> ConsoleApplication1

I just noticed that the magic symbol translation _snprintf -> __snprintf 
isn't included without linking the internal function init_msvc (which is 
normally done by d_run_main which is called by the generated C main).

The current workaround here is to add

extern "C" void __cdecl init_msvc();

to the C source and call it before rt_init. I think we should move it 
into rt_init inside druntime.


More information about the Digitalmars-d-announce mailing list