On 16 October 2013 17:16, Rainer Schuetze <r.sagitario@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.