Bug 15106 – Optlink executed with LDC as compiler?

I select LDC as compiler, it builds and then invokes OPTLINK to link. It's even a 64bit project... I'm using the MSVC LDC build, it should use Microsoft's linker like DMD no? Building .\dsignal.exe... OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Warning 9: Unknown Option : NXCOMPAT OPTLINK : Warning 9: Unknown Option : DYNAMICBASE OPTLINK : Error 8: Illegal Filename /NOLOGO /NXCOMPAT /DYNAMICBASE /LARGEADDRESSAWARE /OPT:REF /OPT:ICF "/OUT:.\dsignal.exe" analyse.obj fft.obj stft.obj util.obj wave.obj window.obj plot.obj image.obj sound.obj normint.obj conv.obj hsx.obj package.obj rgb.obj xyz.obj test.obj "/LIBPATH:C:\dev\ldc2-0.16.0-alpha4-win64-msvc\bin/../lib" legacy_stdio_definitions.lib /LARGEADDRESSAWARE:NO "/MAP:obj\x64\Release\dsignal.map" /SUBSYSTEM:CONSOLE phobos2-ldc.lib druntime-ldc.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib ^ Error: C:\dev\D\dmd2\windows\bin\link.exe failed with status: 1 Building .\dsignal.exe failed! You can see from the lib path that it's definitely invoking LDC to build.

http://forum.dlang.org/post/[email protected] This is a common problem with compiler installers: you get PATH polluted with everything you ever installed, then something from that mess gets run when you try to invoke something else.

Is it really ideal to leave sourcing of the path to blind luck? Surely LDC can invoke microsoft's linker specifically? It's true, this is a very general problem. Pathing in general just doesn't work reliably. We need better solutions across the ecosystem. Perhaps software can attempt to identify if the first tool it finds is the correct tool, and then keep looking if it's not...?

The Visual Studio ecosystem works much the same way, though. This is why there is an extra command prompt to launch stuff with the MSVC tools on the PATH (plus of course some other env vars).

But I've _never_ had a single problem with visual studio of this sort in 16 years. I often have 3 or 4 versions of VS installed in parallel, they all just work together. Those command prompts do exist, but they're transparent to the end-user, it runs them when it needs them. I think those command prompts demonstrate that MS understand the pathing struggle, and they fixed it in a way that other stuff on the users systems tends not to interfere with. My point is, the D ecosystem across the board (not just picking on LDC here), needs to be more creative about solving this problem. It's tiring, and it basically hasn't changed for 6 years that I've been here. I had 3 distinct instances of pathing problem yesterday alone. Perhaps LDC (or VisualD?) should leverage those command prompts when building against the MSVC ecosystem (ie, LDC, DMD), rather than just hoping the path is configured correctly? Windows users don't do path management, it's always a complete mess.

(In reply to Manu from comment #4) > I think those command prompts demonstrate that MS understand the pathing > struggle, and they fixed it in a way that other stuff on the users systems > tends not to interfere with. The solution is to NOT put the toolchain in PATH system-wide. That's the best solution so far and the way MS toolchain works (and the very reason why MS toolchains can work side by side with each other on the same system). > Perhaps LDC (or VisualD?) should leverage those command prompts when > building against the MSVC ecosystem (ie, LDC, DMD), rather than just hoping > the path is configured correctly? Windows users don't do path management, > it's always a complete mess. The mess is done by dmd installer to address demands that dmd must work out of the box no matter what. This is done by mangling PATH system-wide to dmd's bidding and breaking other tools, but it achieves the goal: dmd works. MS tools don't mangle PATH because it's not interoperable - the very issue you suffer. So whoever touches PATH is responsible for the mess - it's dmd installer in this case.

(In reply to Manu from comment #4) > Perhaps LDC (or VisualD?) should leverage those command prompts when > building against the MSVC ecosystem (ie, LDC, DMD), rather than just hoping > the path is configured correctly? Windows users don't do path management, > it's always a complete mess. LDC is the wrong place to do it; after all, you might want to use it with different MSVC versions (even though currently you really want to be using VS 2015). We could of course add some heuristics to LDC to try and guess the version the user wants to use. I'm not sure whether it is worth the effort, but I'm sure that if you provide a patch, Kai and Martin will consider it.

Why is 2015 preferable? You're probably right, this is mostly problems for VisualD, but then again, it could be that an LDC installation intelligently configures itself to 'work' against detected toolsets, without resorting to the system's PATH. I suggested in another bug that the DMD installer could be repurposed for LDC too, which does useful MSVC path wrangling and sc.ini configuration. Do you think it would be appropriate for LDC to have such an installer which configured ldc2.conf similarly? If LDC has formal installation, it may make it easier for VisualD to detect installation and auto-configure LDC to work in Visual Studio?

(In reply to Manu from comment #7) > Why is 2015 preferable? Because of the improved C99 support (e.g. for string formatting functions). > Do you think it would be appropriate for LDC to have such an installer which > configured ldc2.conf similarly? If LDC has formal installation, it may make > it easier for VisualD to detect installation and auto-configure LDC to work > in Visual Studio? It would definitely be great to have an LDC installer for Windows (distro packages/archives are fine for the other platforms). I don't think anybody is working on this right now; any help would be very much appreciated.

In https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1 the executable search path settings now default to put the VC bin folder before the dmd folder, so whenever a tool calls link.exe or lib.exe without absolute path (dmd uses a path relative to dmd.exe), it should pick up the MS executables.

We (LDC) also auto-detect MSVC installations now, so this should be fixed.

Great! Looking forward to trying all this out next time I do a fresh install :) Thanks everyone for your vigilance!

> We (LDC) also auto-detect MSVC installations now, so this should be fixed. I just realized that LDC checks VSINSTALLDIR, not VCINSTALLDIR which is set by Visual D. This causes the batch with the auto detection to be run, but it uses the highest installed version of VS. That is not necessarily the version I'm not currently working with (and might want to link D code with C++ code). Visual D should probably also set VSINSTALLDIR to disable auto detection in LDC.