Linking issues VisualD generated vs Dub generated projects

Rainer Schuetze r.sagitario at gmx.de
Thu May 16 06:31:10 UTC 2019


Sorry for the late reply, I've been travelling and been busy otherwise.

On 07/05/2019 14:15, ShadoLight wrote:
> I have been toying with Dub generated VisualD projects vs Dub generated
> projects, and ran into some linking issues between x86 vs x64 projects.
> 
> This is out-of-the-box experience on a newly installed VS2015 with DMD
> v2.086.0 and bundled Dub v1.15.0 and VisualD v0.49.2. Note I'm only
> using COFF object format, so this is what newbies will experience if
> they have the same need.
> 
> 1. Creation of x32 project using 'dub init abc32' and all default
> params: Succeeds
> - Building using 'dub build  --arch=x86_mscoff': Build succeeds. Using
> --verbose option I can see dub calls dmd passing -m32mscoff.
> - Creation of VisualD project with 'dub generate visuald': Succeeds
> -- VisualD project created is x64 though. Command line shows -m64
> passed. (I reported this on dub forums).
> -- Note only debug configuraiton of VisualD project is created

Yeah, dub projects only generate a single configuration, that's pretty lame.

> -- Builing from inside VS2015 fails with the same error as described for
> x64 architecture as described below.
> 
> 2. Creation of x32project using VisualD 'New|Project...|Visual D Win32
> Application|Console Application|x86|DMD': Succeeds
> - Note I'm deselecting OMF object format, so building COFF format.
> - Building from inside VS2015: Build fails.
> -- For option: LINK (using C Runtime): Dynamic Release MSCVRT)
> --- LINK : fatal error LNK1181: cannot open input file 'user32.lib'
> -- LINK (using C Runtime): Static Release LIBCMT)
> --- LINK : fatal error LNK1181: cannot open input file 'user32.lib'
> 
> Investigating I found that the [Environment32] and [Environment64]
> sections sc.ini file has not been updated to reflect the new directory
> structure inside c:\D\dmd2\windows\lib64\ as well as
> c:\D\dmd2\windows\lib32mscoff\.
> 
> Modifying these sections to...
> [Environment64]
> LIB=%@P%\..\lib64;%@P%\..\lib64\mingw;
> DFLAGS=%DFLAGS% -L/OPT:NOICF
> 
> [Environment32mscoff]
> LIB=%@P%\..\lib32mscoff;%@P%\..\lib32mscoff\mingw
> DFLAGS=%DFLAGS% -L/OPT:NOICF

You should not add these library paths, these are automatic fallback for
dmd if it doesn't find a VS installation.

Instead you should install any Windows SDK (e.g. the one that comes with
the VS installer). I've recently updated the installation documentation
to that respect.

> 
> Now the VisualD x32 COFF project builds/runs successfully.

> 
> However, this does not solve the issue with x64 applications.
> 
> 3. Creation of x32project using VisualD 'New|Project...|Visual D Win32
> Application|Console Application|x64|DMD': Succeeds
> - Building from inside VS2015: Build fails.
> -- LINK (using C Runtime): Dynamic Release MSCVRT)
> --- msvcrtd.lib(utility_desktop.obj) : error LNK2019: unresolved
> external symbol __imp_RtlLookupFunctionEntry referenced in function
> __scrt_fastfail
> --- msvcrtd.lib(gs_report.obj) : error LNK2001: unresolved external
> symbol __imp_RtlLookupFunctionEntry
> --- msvcrtd.lib(utility_desktop.obj) : error LNK2019: unresolved
> external symbol __imp_RtlVirtualUnwind referenced in function
> __scrt_fastfail
> --- msvcrtd.lib(gs_report.obj) : error LNK2001: unresolved external
> symbol __imp_RtlVirtualUnwind
> -- LINK (using C Runtime): Static Release LIBCMT)
> --- libcmtd.lib(utility_desktop.obj) : error LNK2019: unresolved
> external symbol __imp_RtlLookupFunctionEntry referenced in function
> __scrt_fastfail
> --- libcmtd.lib(gs_report.obj) : error LNK2001: unresolved external
> symbol __imp_RtlLookupFunctionEntry
> --- libucrtd.lib(invalid_parameter.obj) : error LNK2001: unresolved
> external symbol __imp_RtlLookupFunctionEntry
> --- libvcruntimed.lib(trnsctrl.obj) : error LNK2001: unresolved external
> symbol __imp_RtlLookupFunctionEntry
> --- libcmtd.lib(utility_desktop.obj) : error LNK2019: unresolved
> external symbol __imp_RtlVirtualUnwind referenced in function
> __scrt_fastfail
> --- libcmtd.lib(gs_report.obj) : error LNK2001: unresolved external
> symbol __imp_RtlVirtualUnwind
> --- libucrtd.lib(invalid_parameter.obj) : error LNK2001: unresolved
> external symbol __imp_RtlVirtualUnwind
> --- libvcruntimed.lib(_chandler_.obj) : error LNK2019: unresolved
> external symbol __imp_RtlUnwindEx referenced in function
> __C_specific_handler
> --- libvcruntimed.lib(trnsctrl.obj) : error LNK2001: unresolved external
> symbol __imp_RtlUnwindEx
> --- libvcruntimed.lib(_jmpuwind_.obj) : error LNK2019: unresolved
> external symbol RtlUnwindEx referenced in function _local_unwind
> --- libvcruntimed.lib(frame.obj) : error LNK2019: unresolved external
> symbol __imp_RtlPcToFileHeader referenced in function __CxxExceptionFilter
> --- libvcruntimed.lib(throw.obj) : error LNK2001: unresolved external
> symbol __imp_RtlPcToFileHeader

Again, wrong libraries. The import libs in the mingw folder are for the
VS2010 runtime, not anything newer.

> This makes me think it is finding the wrong msvcrtd.lib or libcmtd.lib.
> I can see there are x32 and x64 versions of msvcrt100.lib under
> c:\D\dmd2\windows\lib32mscoff\mingw\ and c:\D\dmd2\windows\lib64\mingw\
> (but only release versions). But I cannot find any libcmt*.lib files
> under c:\D\dmd2\windows\*.
> 
> If I try to add them manually I get a bunch of of "...already defined in
> msvcrt100.lib(msvcr100.dll)". I am anyway sure it should not be
> necessary to add the C runtime libs manually to the project.
> 
> How do I get the x64 versions to link using VS2015? (I am pretty sure
> this was working in earlier versions of VisualD).

I guess you had a Windows SDK installed then.

> 
> Also, note you have a typo in VisualD GUI under LINK C Runtime drop :
> Dynamic Debug/Release MSCVRT) - it should be MSVCRT, not MSCVRT.

Thanks, fixed.


More information about the Digitalmars-d-ide mailing list