Beta D 2.069.0-b1

[Rainer Schuetze via Digitalmars-d-announce]

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.