On Tuesday, 15 October 2013 at 06:24:28 UTC, Brad Anderson wrote:
>
> I'm at a loss for how I would anyway.  My only option might be to add execution of vcvars to the D2 Command Prompt shortcut I make.
>  I'm going to sleep on this and think about it some more.

ah ok, i've never used dmd prompt myself anyway, so i would prefer if there will be script at dmd path which calls that cvars, because i really only use win+r & cmd, with or without dub, or visuald.

VS 2010 Express/Windows SDK 7.0:

dmd -m64 hello.d
Can't run 'c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\link.exe', check PATH

with dmd-2.064-beta-new-sc.ini-2.exe

On Tuesday, 15 October 2013 at 06:37:52 UTC, evilrat wrote:
> On Tuesday, 15 October 2013 at 06:24:28 UTC, Brad Anderson wrote:
>>
>> I'm at a loss for how I would anyway.  My only option might be to add execution of vcvars to the D2 Command Prompt shortcut I make.
>> I'm going to sleep on this and think about it some more.
>
> ah ok, i've never used dmd prompt myself anyway, so i would prefer if there will be script at dmd path which calls that cvars, because i really only use win+r & cmd, with or without dub, or visuald.

Looks like I can probably just stick a:

PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE

in there according to an sc.ini Rainer posted.  I'll check this all out tomorrow.

On Tuesday, 15 October 2013 at 02:17:39 UTC, Brad Anderson wrote:
> There are some pending pull requests[1][2] to get automatic win64 configuration during installation working.  I've prepared a dmd 2.064-beta installer which includes these unmerged changes which you can download here:
>
> http://gnuk.net/dmd-2.064-beta-new-sc.ini.exe
>

Third attempt with help/ideas from Rainer:

http://gnuk.net/dmd-2.064-beta-new-sc.ini-3.exe

I've removed ...-2.exe to avoid confusion.

On Tuesday, 15 October 2013 at 06:38:30 UTC, dnewbie wrote:
> VS 2010 Express/Windows SDK 7.0:
>
> dmd -m64 hello.d
> Can't run 'c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\link.exe', check PATH
>
> with dmd-2.064-beta-new-sc.ini-2.exe

I believe you need the 7.1 SDK.  7.0 does not come with the 64-bit toolset.  I'm not certain about the paths in an Express/7.1 setup.

If you can give me the paths to:

1. 64-bit link.exe
2. 64-bit C Runtime libraries (in MSVC this is %VCINSTALLDIR%lib\amd64 but I'm not sure if that comes with Express or with the 7.1 SDK and is located somewhere in SDK's directory structure instead).

I might be able to this working.

I just tried your '-3' version. It has problems.

1: VisualD installer still asks where you installed DMD; it should be able
to know this since it's being invoked by the DMD installer. I think that
should be fixed.
2: gcstub64.obj and phobos64.lib are still in D/dmd2/windows/lib. They
should be moved to lib64/
3: sc.ini contains: LIB="%@P%\..\lib64";"%@P%\..\lib"   <- why is '../lib/'
still present in [Environment64]? That should be removed, it can only lead
to erroneous attempts to link the OMF libs. Rather have a "can't find lib"
error, than a weird lib format error that most programmers won't understand.
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 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.

Elsewhere in the file, you detect VS2010LINKCMD, VS2013LINKCMD, etc. Why
not also have a matching suite of VS2010LIBPATH="C:\Program Files
(x86)\Microsoft Visual Studio 10.0\VC\lib\amd64" and friends, and refer to
them down the bottom as LIB=%VS2010LIBPATH%;%LIB%, along
with LINKCMD64=%VS2010LINKCMD%.
Ie, detect versions of VS present, produce a VS20##LINKCMD and
VS20##LIBPATH appropriately for each version in their little section, then
at the bottom, assign the actual variables used by DMD to the version
selected by the user when prompted during installation. The result of this
is that sc.ini will be very easy to read and understand, and if the user
later wants to switch to another VS version, it'll be obvious to change the
reference to the VS20## variables.

My primary VS environment is VS2010, which is going to be wrong if the installer uses a 'prefer newest version' strategy.

Another question, why use LINKCMD64? Shouldn't it just be LINKCMD, since it's under the [Environment64] block? You're not using LIB64, or any others like that.

On 16 October 2013 11:15, Brad Anderson <eco@gnuk.net> wrote:

> On Tuesday, 15 October 2013 at 06:38:30 UTC, dnewbie wrote:
>
>> VS 2010 Express/Windows SDK 7.0:
>>
>> dmd -m64 hello.d
>> Can't run 'c:\Program Files (x86)\Microsoft Visual Studio
>> 10.0\VC\bin\amd64\link.exe', check PATH
>>
>> with dmd-2.064-beta-new-sc.ini-2.**exe
>>
>
> I believe you need the 7.1 SDK.  7.0 does not come with the 64-bit toolset.  I'm not certain about the paths in an Express/7.1 setup.
>
> If you can give me the paths to:
>
> 1. 64-bit link.exe
> 2. 64-bit C Runtime libraries (in MSVC this is %VCINSTALLDIR%lib\amd64 but
> I'm not sure if that comes with Express or with the 7.1 SDK and is located
> somewhere in SDK's directory structure instead).
>
> I might be able to this working.
>

On 16.10.2013 04:45, Manu wrote:
> I just tried your '-3' version. It has problems.
>
> 1: VisualD installer still asks where you installed DMD; it should be
> able to know this since it's being invoked by the DMD installer.. I
> think that should be fixed.

I have not yet updated the Visual D installer to pick up the setting. Will do.

> 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.

> 3: sc.ini contains: LIB="%@P%\...\lib64";"%@P%\..\lib"   <- why is
> '../lib/' still present in [Environment64]? That should be removed, it
> can only lead to erroneous attempts to link the OMF libs. Rather have a
> "can't find lib" error, than a weird lib format error that most
> programmers won't understand.

Sure, that should be done when the 64 bit files are moved to their own folder.

> 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.

>
> 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".

>
> Elsewhere in the file, you detect VS2010LINKCMD, VS2013LINKCMD, etc. Why
> not also have a matching suite of VS2010LIBPATH="C:\Program Files
> (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64" and friends, and refer
> to them down the bottom as LIB=%VS2010LIBPATH%;%LIB%, along
> with LINKCMD64=%VS2010LINKCMD%.
> Ie, detect versions of VS present, produce a VS20##LINKCMD and
> VS20##LIBPATH appropriately for each version in their little section,
> then at the bottom, assign the actual variables used by DMD to the
> version selected by the user when prompted during installation. The
> result of this is that sc.ini will be very easy to read and understand,
> and if the user later wants to switch to another VS version, it'll be
> obvious to change the reference to the VS20## variables.
>
> My primary VS environment is VS2010, which is going to be wrong if the
> installer uses a 'prefer newest version' strategy.


>
> Another question, why use LINKCMD64? Shouldn't it just be LINKCMD, since
> it's under the [Environment64] block? You're not using LIB64, or any
> others like that.

There is a already pull request to change this: https://github.com/D-Programming-Language/dmd/pull/2667

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.

On Tuesday, 15 October 2013 at 02:17:39 UTC, Brad Anderson wrote:
>
> This installer also includes support for automatically downloading the Visual D installer and running it (another yet to be merged pull request[3]).
>

with sc-2 config it is almost useless with VisualD, hope next version will be more usable :)

also, does anyone knows why it fails to start debugger on x64 binary using  VisualD?

On Wednesday, 16 October 2013 at 01:15:20 UTC, Brad Anderson wrote:
> On Tuesday, 15 October 2013 at 06:38:30 UTC, dnewbie wrote:
>> VS 2010 Express/Windows SDK 7.0:
>>
>> dmd -m64 hello.d
>> Can't run 'c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\link.exe', check PATH
>>
>> with dmd-2.064-beta-new-sc.ini-2.exe
>
> I believe you need the 7.1 SDK.  7.0 does not come with the 64-bit toolset.  I'm not certain about the paths in an Express/7.1 setup.
>
> If you can give me the paths to:
>
> 1. 64-bit link.exe
> 2. 64-bit C Runtime libraries (in MSVC this is %VCINSTALLDIR%lib\amd64 but I'm not sure if that comes with Express or with the 7.1 SDK and is located somewhere in SDK's directory structure instead).
>
> I might be able to this working.

1. 64-bit link.exe:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Bin\amd64\link.exe

2. 64-bit C Runtime libraries:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib\amd64

3. 64-bit Windows import libraries:
C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\x64