Linking issues VisualD generated vs Dub generated projects

[ShadoLight]

On Wednesday, 22 May 2019 at 08:42:21 UTC, ShadoLight wrote:
> On Thursday, 16 May 2019 at 06:31:10 UTC, Rainer Schuetze wrote:
> [snip]
>>
>> You should not add these library paths, these are automatic 
>> fallback for dmd if it doesn't find a VS installation.
>>
> OK, original state of sc.ini restored.
>
>> 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.
>>
>
> I do in fact have multiple Windows SDKs installed - probably 
> from earlier versions of VS + SDKs I had installed. Under 
> 'c:\Program Files (x86)\Windows Kits\' I still have folders for:
> - 8.0
> - 8.1
> - 10
> - NETFXSDK
>
> The VS uninstall feature does not uninstall the SDKs, so I 
> still have a number of previous SDK versions.
>
> If I revert the original state of sc.ini I still have the issue 
> that it cannot find 'user32.lib' and fails with a linking error.
>
> As mentioned in my previous post there are 'user32.lib' 
> versions under 'c:\D\dmd2\windows\lib64\mingw\' and  
> 'c:\D\dmd2\windows\lib32mscoff\mingw\', but ok, as you 
> indicated, these are for VS2010 and I should link to the 
> versions under my Windows SDK if I have a later version of VS 
> installed.
>
> My *current* set of Library search paths (Tools -> Options -> 
> VisualD Settings -> DMD -> x64) shows:
> $(VCINSTALLDIR)lib\amd64
> $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
> $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64
> $(DMDInstallDir)windows\bin
>
> There is no 'user32.lib' present under $(VCINSTALLDIR)lib\amd64 
> and the
> "$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64" resolve to...
> $(UniversalCRTSdkDir) = C:\Program Files (x86)\Windows Kits\10\
> $(UCRTVersion)= 10.0.10240.0
>  .... eg. the latest Windows SDK installed (v10).
>
> There is no 'user32.lib' present here either (c:\Program Files 
> (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x64\).
>
> OTOH, there is a 'user32.lib' present in c:\Program Files 
> (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\ i.e. under Windows 
> SDK 8.1. If I add this path to the Library search paths the app 
> now successfully links - and my very trivial test program runs 
> fine.
>
> Interestingly, I found I only have 'user32.lib' present in 
> Windows SDK 8.1, but in neither of 8.0 or 10.0.
>
> The exact same story also applies to x32 COFF libs. At this 
> point I can easily add the SDK 8.1 to the Library search seach 
> paths for x64 and x32COFF, but is it a good idea to mix SDK 10 
> and 8.1 like this? The search order will link to libs from 10 
> if they are present in SDK 10, and only use libs from SDK 8.1 
> if they are not present in SDK 10.
>
> I am rather going to change my Lib search paths to only use the 
> SDK 8.1, but are these known restrictions with SDK 8.0. and 
> 10.0? Or is there something wrong with my SDK 10 installation? 
> (I have 2 versions of SDK 10, and both show very few libs 
> compared to 8.1)

Wow... have now found I cannot fix this linking issue by sticking 
just with libs from SDK 8.1.

If I remove the search path to libs from SDK 10.0, a basic D app 
now fails to link because of a missing 'libucrtd.lib', which I 
can only find under SDK 10. And likewise can only find 
'user32.lib' under SDK 8.1.

This is becoming really strange now... do I really need 2 
versions of the Windows SDK to be able to build using VisualD 
under VS 2015? Or are one (or both) of my SDKs broken?

To make linking succeed my lib search paths for x64 now looks 
like this:

$(VCINSTALLDIR)lib\amd64
"c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64"  
<-SDK 8.1 path hard-coded
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64  <-'Default' 
SDK; v10.0 in this case
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64
$(DMDInstallDir)windows\bin

I also don't understand (even thought this is not an issue for me 
at the moment since I am not targeting ARM), how the 'default' 
global search paths here for both ARM and x32/x64 can co-exist...
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64

... the above search order will always cause an ARM target to 
find the corresponding x32/x64 lib first - and try to link to 
that (since the basic ARM/x32/x86 lib names (like user32.lib) are 
all identical). Or are there some trick to this that I am missing?

In fact, why even have ARM lib search paths under the DMD 
compiler settings? AFAIK you cannot target ARM anyway with DMD, 
no? ARM paths may be valid paths for LDC or GDC, but VisualD has 
separate forms for those paths - I am just referring to the  DMD 
case here.

I know you can specify the lib search paths at a local project 
level too, but these DMD 'global' search paths (with the 
exception of the SDK 8.1 one I added) were created by the VisualD 
installer, so this was actually my 'default' installation.

I would like to seamlessly switch from building with dub to 
debugging with VS+VisualD (after generating VisualD project using 
dub) if required - this should actually be pretty much the 
standard work-flow for users of VS+VisualD and allows to leverage 
the strength of both. But I have also found some issues on the 
dub side as well with generating VisualD projects. I'll have a 
stab at fixing them but I want to use VS+VisualD to debug dub for 
this so, even though I can successfully compile+link at the 
moment in VS+VisualD, I'm suspicious of having to link against 
libs from 2 SDKs...?