Help needed testing automatic win64 configuration

[Manu]

On 16 October 2013 17:16, Rainer Schuetze <r.sagitario at gmx.de> wrote:

>
>
> On 16.10.2013 04:45, Manu wrote:
>
>>
>>  2: gcstub64.obj and phobos64.lib are still in D/dmd2/windows/lib. They
>> should be moved to lib64/
>>
>
> We are trying to talk Walter into doing this but it seems there are topics
> that fail to gain traction.
>

Cool, well if it get's there, I should add that it would be nice to lose
the '64' suffix too. No reason for them to have different filenames if
they're in lib64/. Just creates extra annoying logic in build scripts.


 4: It fails to find the Microsoft libs. Here is the relevant parts of my
>> sc.ini as installed by the installer:
>>
>> LIB="%@P%\..\lib64";"%@P%\..\**lib"
>>
>> ;;;; search path for C Runtime libraries
>> ; the following lib path works with VS2008, VS2010, VS2012, VS2013
>> ; prepending because 32-bit OMF versions can cause link.exe to fail
>> LIB="C:\Program Files (x86)\Microsoft Visual Studio
>> 11.0\VC\lib\amd64";%LIB%
>>
>> ;;;; search path for Platform libraries
>> ; the following lib path works with Windows SDK 6.x and 7.x
>> LIB="C:\Program Files (x86)\Windows Kits\8.0\lib\winv6.3\um\x64";%**LIB%
>>
>> ; the following lib path works with Windows SDK 8.0 and 8.1
>> LIB="%WindowsSdkDir%Lib\win8\**um\x64";%LIB%
>>
>>
>> I have VS2010 and VS2012 installed on a Win8 machine. I have libs in
>> these locations:
>>
>> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64  <- this one
>> seems to be unknown to the installer. These libs should be used in
>> conjunction with VS2010.
>> C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64  <- the
>> installer refers to %WindowsSdkDir%, which is not present on my system.
>> Use the absolute path instead? These libs are to use used in conjunction
>> with VS2012.
>> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64  <-
>> runtime libs, how to pick which version? Prompt during installation?
>> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64  <-
>> runtime libs, how to pick which version? Prompt during installation?
>>
>> I should note that I think VisualD needs to do some work here too.
>> VisualD should override the linker and lib paths, since it has more
>> information.
>> Ie, how does cmdline DMD choose which linker/runtime libs to use?
>> Perhaps a prompt during installation? Choose the newest (appears to be
>> the current behaviour).
>> Whereas VisualD will be running inside of an instance of either VS2010
>> or VS2012 (I use both, this is very common practise) on my machine, and
>> it should configure the linker and lib paths appropriately for the
>> version of VisualStudio currently in use when building, otherwise there
>> will be link troubles against C/C++ libraries also being built in the
>> same solution (yes, it's common to have C/C++ and D in the same solution).
>>
>
> The installer tries to pick the latest version of both VS and SDK
> installations. I see there is a problem when selecting a different C
> runtime than what your C/C++ code is assuming. Is the Windows-SDK a
> problem, too? The files used are just import libraries, so the latest
> should be fine as long as you don't need linker errors when you build an
> application to be run on XP but are calling Win8 only functions.
>

You're probably right about the system library path. I haven't had any
issues of this sort, but I just tend to be behave conservatively when it
comes to this sort of thing. There are so many unexpected ways that linking
goes wrong in the windows ecosystem.

The runtime libraries are definitely a problem. The 'select most recent'
policy is incorrect in my case. VS2010 is the environment I do 99% of my
work, and I have experienced issued when C and D projects are together in
the same solution.
I'm not sure what the best solution is here. My feeling is that a prompt in
the installer to offer which version to hook up as the default, and VisualD
overriding these variables somehow.
There's no way for VisualD to override this variable when invoking the
compiler? You mention below that it would only be possible with separate
linkage, why is that?


For clarity, on my system, when using the VS2010 compiler, it should use
>> these lib paths:
>>    runtime libs: C:\Program Files (x86)\Microsoft Visual Studio
>>
>> 10.0\VC\lib\amd64
>>    windows libs: C:\Program Files (x86)\Microsoft
>> SDKs\Windows\v7.0A\Lib\x64    <- AFAIK, Microsoft SDKs is the old
>> location, installed with VS2010 and earlier.
>>
>> When using the VS2012 compiler, it should use these paths:
>>    runtime libs: C:\Program Files (x86)\Microsoft Visual Studio
>>
>> 11.0\VC\lib\amd64
>>    windows libs: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64
>>     <- Windows Kits is the new location, by versions > VS2010 (AFAIK).
>>
>>
>> The default installation of DMD using your new installer fails to link
>> on my machine because %WindowsSdkDir% is not defined on my system, and
>> since the 32bit dmd lib path is still present, it tries to link the OMF
>> libs, and complains a lot.
>>
>
> It seems the installer failed to replace two occurences of
> %WindowsSdkDir%. WindowsSdkDir is set by batch files vsvars32.bat and
> friends. I see conflicting goals here:
>
> 1. the installer expands variables WindowsSdkDir and VCINSTALLDIR in
> sc.ini to work without running vsvars32.bat. It has to make decisions on
> what versions to pick up.
>
> 2. when running dmd by Visual D you want to select settings according to
> the current Visual Studio, which means it needs the unexpanded variables.
>
> The current option to allow both is to not run the linker through dmd, but
> invoke it "manually".
>

What do you mean by 'manually' exactly?
Is there anything that can be done in VisualD to override these variables
when invoking the compiler?


There's one other detail that I forgot in my prior email; I think it would
be really handy to include the DirectX lib path by default.
It's a very standard MS lib package, and anyone who does multimedia
development will surely have it on their system, and require it to be
hooked up.
My DX libs are here: C:\Program Files (x86)\Microsoft DirectX SDK (June
2010)\Lib\x64
It seems I have an environment variable: DXSDK_DIR=C:\Program Files
(x86)\Microsoft DirectX SDK (June 2010)\
It also seems to register a presence in the registry at:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DirectX\Microsoft DirectX
SDK (June 2010)\InstallPath

I usually have more faith in the registry, but the env variable is surely
going to be present on everyone's machine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131016/c232b486/attachment-0001.html>