On 17 October 2013 02:51, dnewbie <run3@myopera.com> wrote:

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

That looks like VS2008, does VisualD work under VS2008?
Either way, the DMD installer should support detection of those paths too.

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

FYI, the 7.1 SDK is a downloadable SDK, it's not included with any version
of Visual Studio.
7.0 and 7.0A (included with VS2008, 2010) certainly do have 64bit libs.

The x64 compiler was available since VS2005 (I don't remember the lib path).
VS2008 uses the 'Microsoft SDKs/Windows/v7.0', and VS2010 uses 'Microsoft
SDKs/Windows/v7.0A'.
The 7.1 package that you can download if obviously in 'Microsoft
SDKs/Windows/v7.1'.

VS2012 was the first to support Windows 8 and the 'metro' API, and for some
reason they messed around with the traditional lib paths.
The new location is the weird 'Windows Kits\8.0'.

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 Thursday, 17 October 2013 at 00:03:15 UTC, Manu wrote:
> 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.
>>
>
> FYI, the 7.1 SDK is a downloadable SDK, it's not included with any version
> of Visual Studio.
> 7.0 and 7.0A (included with VS2008, 2010) certainly do have 64bit libs.
>
> The x64 compiler was available since VS2005 (I don't remember the lib path).
> VS2008 uses the 'Microsoft SDKs/Windows/v7.0', and VS2010 uses 'Microsoft
> SDKs/Windows/v7.0A'.
> The 7.1 package that you can download if obviously in 'Microsoft
> SDKs/Windows/v7.1'.
>
> VS2012 was the first to support Windows 8 and the 'metro' API, and for some
> reason they messed around with the traditional lib paths.
> The new location is the weird 'Windows Kits\8.0'.

I was referring only to VS 2010 Express which does not include a compiler/linker capable of building 64 bit code.  You can get them with the 7.1 SDK though.

More information: http://stackoverflow.com/questions/1865069/how-to-compile-a-64-bit-application-using-visual-c-2010-express

On Wednesday, 16 October 2013 at 02:45:26 UTC, Manu wrote:
> I just tried your '-3' version. It has problems.
> [snip]
> 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.

I agree. It's just a matter of getting Walter on board.  He hasn't said yay or nay to lib64 but he's just put sc.ini in the repo now for hot steamy pull request action so I think he's probably down.

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

Very odd that it replaced one instance of %WindowsSdkDir% but not the last one (the installer does a find and replace on some of the environment variables with the paths it has detected from the registry). It probably has to do with the lack of newline on that final line in the file. I'll fix that before this next attempt.


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

I'm switching to a simpler approach for this next iteration which I will post shortly.

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

I'll see what I can do but I may run out of time to get this in for 2.064. I think prefer newest is probably a good default but I'm open to hearing why that might not be the case.

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

I think others mentioned this but this has already been fixed.

before i tried x64 i was happy to see its finally coming to the masses, but now, *cough* excuse me, how can we develop x64 apps if we can't hook debugger? is this something with my configuration or something on dmd part which denies any possibility to use debuggers at this moment?

Attempt four: http://gnuk.net/dmd-2.064-beta-newsc-lib64-4.exe

This one has a couple more changes to the dmd2beta.zip it is downloading from my server.

1. dmd.exe has been replaced with one built from 2.064 branch HEAD (so I didn't have to use LINKCMD64).
2. lib64 has been added and phobos64.lib and gcstub64.lib have been moved into there from lib.

On Thursday, 17 October 2013 at 05:27:15 UTC, Brad Anderson wrote:
> I'm switching to a simpler approach for this next iteration which I will post shortly.
>

http://gnuk.net/dmd-2.064-beta-newsc-lib64-4.exe

On Thursday, 17 October 2013 at 06:15:43 UTC, evilrat wrote:
> before i tried x64 i was happy to see its finally coming to the masses, but now, *cough* excuse me, how can we develop x64 apps if we can't hook debugger? is this something with my configuration or something on dmd part which denies any possibility to use debuggers at this moment?

This is above my paygrade. Perhaps Walter or Rainer can answer.

On Thursday, 17 October 2013 at 06:17:57 UTC, Brad Anderson wrote:
> On Thursday, 17 October 2013 at 05:27:15 UTC, Brad Anderson wrote:
>> I'm switching to a simpler approach for this next iteration which I will post shortly.
>>
>
> http://gnuk.net/dmd-2.064-beta-newsc-lib64-4.exe

now it builds and links just from the box(tested with console dmd build). will test with visuld later.

On 16.10.2013 13:13, Manu wrote:
> On 16 October 2013 17:16, Rainer Schuetze <r.sagitario@gmx.de
>     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.

I agree.

[...]
>
>     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?
>
[...]
>
>     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?

By "manually" I mean that the linker is not run through dmd, but is called directly from the batch generated by Visual D. This means, Visual D has to extract all the settings from sc.ini and rebuild the command line that dmd would generate. In addition, it needs to know which settings have to be replaced and which have been set deliberately by the user.

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

I'm not sure we should add too many special cases, everybody has his own set of favorite libraries (I haven't touched DirectX for more than 10 years). Considering that you probably have to make your own imports for the respective declarations, I think it is ok to add an appropriate library path to your project aswell.

It seems the DX-SDK does not end up in the LIB environment variable for the VS command prompt aswell, though I see it added in the Visual Studio settings.