On 16.10.2013 04:45, Manu wrote:
We are trying to talk Walter into doing this but it seems there are topics that fail to gain traction.2: gcstub64.obj and phobos64.lib are still in D/dmd2/windows/lib. They
should be moved to lib64/
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.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).
For clarity, on my system, when using the VS2010 compiler, it should useruntime libs: C:\Program Files (x86)\Microsoft Visual Studio
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:
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".