Linking issues VisualD generated vs Dub generated projects

[ShadoLight]

On Saturday, 30 November 2019 at 08:53:32 UTC, Rainer Schuetze 
wrote:
>
>
> On 30/11/2019 00:59, ShadoLight wrote:
>> On Wednesday, 22 May 2019 at 20:12:49 UTC, Rainer Schuetze 
>> wrote:
>>> On 22/05/2019 19:32, Rainer Schuetze wrote:
>>>>
>>>> The VS2015 default for x64 is:
>>>>
>>>> $(VCINSTALLDIR)lib\amd64
>>>> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
>>>
>>> Argh, sorry, this is what you get without any Windows SDK 
>>> installed. If the Win10 SDK is detected, this gets added, too:
>>>
>>> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64
>>>
>>>>
>>>> and for Win32-COFF:
>>>>
>>>> $(VCINSTALLDIR)lib
>>>> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86
>>>
>>> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86
>>>
>>>>
>>>> Starting with VS2015, the VC runtime requires the universal 
>>>> runtime
>>>> (UCRT).
>>>>
>>>> You can see the resulting paths in the build logs in the 
>>>> output directory. The are passed to the linker with the 
>>>> /LIBPATH option.
>> 
>> Many moons later... on a new clean Win7 x64 laptop with VS2015 
>> Pro I had a chance to start from scratch and see what happens 
>> with the above SDK scenario:
>> 
>> After a "clean" install of DMD (2.089.0) and VisualD (0.50.1), 
>> I got the
>> following VD Library Paths:
>> Win32:
>> (empty)
>> x64:
>> $(VCINSTALLDIR)lib\amd64
>> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
>> Win32-COFF:
>> $(VCINSTALLDIR)lib
>> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86
>> 
>> I did not get the following 2 paths (you mentioned above) 
>> added:
>> x64:
>> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64
>> Win32-COFF:
>> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86
>> 
>> So neither the paths for the Win10 SDK nor Wn8.1 SDK were 
>> added.
>> 
>> Creating a Win32 app in VS then fails with "LNK1181: cannot 
>> open input file 'user32.lib'".
>> 
>> Adding the above 2 paths for Win10 SDK does not solve the 
>> above Link error - it still cannot link to 'user32.lib'. From 
>> the calc2.buildlog.html I can see:
>> 
>> /LIBPATHs: C:\Program Files (x86)\Microsoft Visual Studio 
>> 14.0\VC\lib;
>>     C:\Program Files (x86)\Windows 
>> Kits\10\Lib\10.0.10240.0\ucrt\x86;
>>     C:\Program Files (x86)\Windows Kits\10\lib\\um\x86
>> 
>> This gives the following values:
>> $(VCINSTALLDIR): C:\Program Files (x86)\Microsoft Visual 
>> Studio 14.0\VC
>> $(UCRTSdkDir): C:\Program Files (x86)\Windows Kits\10
>> $(UCRTVersion): 10.0.10240.0
>> $(WindowsSdkDir): C:\Program Files (x86)\Windows Kits\10
>> $(WindowsSdkVersion):
>> 
>> This seems to indicate VD thinks Win10 SDK is installed. 
>> However, even though there is a "c:\Program Files 
>> (x86)\Microsoft SDKs\Windows\v10.0A\" folder, there is no Lib 
>> folder in it neither any *.lib files.
>> 
>> Searching for 'user32.lib' in C:\Program Files (x86) I get:
>> c:\Program Files (x86)\Microsoft 
>> SDKs\Windows\v7.1A\Lib\User32.Lib
>> c:\Program Files (x86)\Microsoft 
>> SDKs\Windows\v7.1A\Lib\x64\User32.Lib
>> c:\Program Files (x86)\Windows 
>> Kits\8.1\Lib\winv6.3\um\arm\User32.Lib
>> c:\Program Files (x86)\Windows 
>> Kits\8.1\Lib\winv6.3\um\x64\User32.Lib
>> c:\Program Files (x86)\Windows 
>> Kits\8.1\Lib\winv6.3\um\x86\User32.Lib
>> 
>> Replacing $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86 with 
>> a
>> hardcoded "c:\Program Files (x86)\Windows
>> Kits\8.1\Lib\winv6.3\um\x86\User32.Lib" solves the Linking 
>> issue - app
>> is build and runs successfully.
>> 
>> But this indicates to me that the required SDK on my machine 
>> is actually
>> Win8.1 SDK. And for $(WindowsSdkDir) should be "c:\Program 
>> Files
>> (x86)\Windows Kits\8.1\" and for $(WindowsSdkVersion) should 
>> be "winv6.3".
>> 
>> I cross-checked in VC++ whether these enviro variables are 
>> defined and
>> what their values are in VC++ and get:
>> $(WindowsSdkDir): "c:\Program Files (x86)\Windows Kits\8.1\"
>> $(WindowsSdkVersion): Not defined at all.
>> 
>> So it seems VC++ correctly maps to the Win8.1 SDK, but not VD. 
>> I'm actually surprised by this... surely  $(WindowsSdkDir) 
>> should be the same for both...?
>> 
>> IS it possible to set/change these enviro variables for VD to 
>> their proper values?
>> 
>> 
>
> As the Windows SDK environment variable is usually not set in 
> the system environment, Visual D mimicks vcvarsall.bat from the 
> VC installation to determine it and uses the first hit:
>
Hi Rainer,

Thanks for the very prompt reply!

Ok, checking this...

> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows 
> Kits\\Installed Roots\\KitsRoot10 and checks if it has a lib 
> folder
--> No KitsRoot10 present.
--> Only KitsRoots present under 
HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\:
         ..\\KitsRoot: C:\Program Files (x86)\Windows Kits\8.0\
         ..\\KitsRoot81: C:\Program Files (x86)\Windows Kits\8.1\
>
> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft 
> SDKs\\Windows\\v8.1\\InstallationFolder and checks if it has a 
> lib folder
--> This is close, but no banana! There are 3 SDKs listed under 
KLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\... namely 
v7.1A, v8.0A and v8.1A. But note that it is *v8.1A*, not *v8.1*. 
But there are anyway no lib folder at the registry entry for 
v8.1A.

>
> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft 
> SDKs\\Windows\\v8.0\\InstallationFolder and checks if it has a 
> lib folder
--> Same story as previous check.. it has *v8.0A*, not *v8.0*. 
Also, no lib folder present at registry entry for v8.0A.

>
> - read registry entry SOFTWARE\\Microsoft\\Microsoft 
> SDKs\\Windows\\CurrentInstallFolder and checks if it has a lib 
> folder
--> The registry entry is 'C:\Program Files (x86)\Microsoft 
SDKs\Windows\v8.1A\', which has no 'lib' folder.

>
> - environment variable WindowsSdkDir
--> Set to 'C:\Program Files (x86)\Windows Kits\10'according to 
buildlog.html.
>
> Could you please check where it gets the "C:\Program Files 
> (x86)\Windows
> Kits\10" folder from?
--> I really have no idea, since it does not look like there is 
any 'hit' from the above.
>
> Usually, the library search path are set once, and they are not 
> altered automatically later. You can reevaluate the default 
> settings with the "Reset Settings..." button.

OK, thanks - I will try this.

On my system it looks like the valid entries were all under 
HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\.., so 
the following sequence would have been preferable (still taking 
the 1st hit):

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows 
Kits\\Installed Roots\\KitsRoot10 and checks if it has a lib 
folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows 
Kits\\Installed Roots\\KitsRoot81 and checks if it has a lib 
folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows 
Kits\\Installed Roots\\KitsRoot80 and checks if it has a lib 
folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows 
Kits\\Installed Roots\\KitsRoot and checks if it has a lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft 
SDKs\\Windows\\v8.1\\InstallationFolder and checks if it has a 
lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft 
SDKs\\Windows\\v8.0\\InstallationFolder and checks if it has a 
lib folder

- read registry entry SOFTWARE\\Microsoft\\Microsoft 
SDKs\\Windows\\CurrentInstallFolder and checks if it has a lib 
folder

- environment variable WindowsSdkDir