original report: http://www.dsource.org/projects/visuald/ticket/276
reported 08/28/13 10:35:50 by TurkeyMan for version 0.3.36
bug in Language Service
So I created a new 'Windows Application' project via the wizard, I then added the x64 platform via the configuration manager, copying from the Win32 settings.
Hit build, it does compile to 64bit code, but then it complains linking:
C:\dev\D\dmd2\windows\bin\..\lib\ole32.lib : warning LNK4003: invalid library format; library ignored
C:\dev\D\dmd2\windows\bin\..\lib\kernel32.lib : warning LNK4003: invalid library format; library ignored
C:\dev\D\dmd2\windows\bin\..\lib\user32.lib : warning LNK4003: invalid library format; library ignored
C:\dev\D\dmd2\windows\bin\..\lib\comctl32.lib : warning LNK4003: invalid library format; library ignored
C:\dev\D\dmd2\windows\bin\..\lib\comdlg32.lib : warning LNK4003: invalid library format; library ignored
C:\dev\D\dmd2\windows\bin\..\lib\uuid.lib : warning LNK4003: invalid library format; library ignored
LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib'
It's trying to link the omf libs supplied with DMD, and then failing to link the CRT.
There's nothing in the project configuration giving it wrong paths.
I'm sure I've done this before when you first added DMD64 support, it worked straight up, but this time I'm seeing these link errors.
I was under the impression that DMD internally looked for the CRT in Microsoft's standard paths, and presumably the windows default lib path too, but apparently it isn't getting through.
Is this a missing command line option, or should DMD be working this out internally?
Comment 1: 08/28/13 13:42:03 by sagitario
The library paths are usually set up in dmd's sc.ini. Does it work from the command line? Have you ever tried to build a windows application before?
Without any configuration in sc.ini, dmd only works with a standard setup of VS2010. The best way is to add a new evironment block [Environment64] and specify library paths for Win64 only. Put the lib path to phobos64.lib at the end so the omf libraries are found last, or better move it to another directory:
[Environment64]
LIB="c:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64";"c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64";"%@P%\..\..\lib"
Comment 2: 08/28/13 22:18:26 by TurkeyMan
Right. Well I do have VS2010 installed, standard setup.
This is a fresh new machine. I haven't used DMD-windows on it yet.
On my previous machine, it just worked out of the box.
I'll amend the config file manually.
I wonder if it's worth VisualD adding paths for the particular version of VisualStudio? in use? VisualD might want to override default settings to tailor it for active environment?
Users might appreciate an "it works out of the box" experience no matter which version of VS they are using. That aspect of the experience is very important when it comes to first impressions.
Comment 3: 08/29/13 02:03:17 by sagitario
I agree, but it would be even better if dmd works out of the box on most VS installations. I had suggested adding some small additions to the ini-file parsing (reading registry keys), but it didn't really catch and the discussion digressed about file format. Unfortunately it is not so easy to make pull requests for that because it has impact on dmd, the auto tester, and the release build script.
Comment 4: 08/30/13 12:11:50 by TurkeyMan
I think the main problem is that if multiple versions of visual studio are installed (common), DMD can't know which one to use. Visual-D can know which paths to hook up, since it's running inside the version of VS that the user intends to use.