Bug 14558 – Attempts to link with DMD when using MSVC LDC under VisualD

I have a VisualD project, and I've configured to build with LDC. It is a Win64 project, and I'm using the MSVC Win64 LDC compiler. (ldc2-0.15.2-beta1-win64-msvc) Trouble is, it seems to try and link with DMD... is that right? It errors: 1>Digital Mars Librarian Version 8.02n 1>Copyright (C) Digital Mars 2000-2007 All Rights Reserved 1>http://www.digitalmars.com/ctg/lib.html 1>Warning: Unknown switch 'out' in command line, ignored. 1> 1>Error: Expecting 'Y' or 'N', not 'O'. 1>Error: C:\dev\D\dmd2\windows\bin\lib.exe failed with status: 1 1>"Output\lib\Release_x64\dud.lib" not created! 1>Building Output\lib\Release_x64\dud.lib failed!

Looks like you are trying to link a library. LDC probably needs lib.exe from the VC distribution, but it picks up lib.exe from the DMD bin folder. I suspect you have the DMD folder in your PATH or it is added to the "Executable Paths".

That sounds like the problem. It is in the path. I don't think it's good to rely on user path configuration for this to work. There is already code where VisualD overrides the VS tool paths with the proper locations relative to the version of VS the user is running right? Linking LDC can never work with DMD's lib.exe, so it should probably be jigged so that it uses the same linker that DMD-Win64 uses when building libs, irrespective of the users path settings?

It's LDC that is calling lib.exe, so probably the best Visual D can do is to add the path to the VC bin folder to the "Executable Paths" by default. For the mingw version of LDC, it cannot guess the path to the respective bin folder, though.

Oh okay. Will adding it to the Executable Paths cause it to take precedence over other paths already in $PATH? MinGW LDC is probably of fairly limited use... I imagine more MinGW users would want to use GDC? Seems more conventional to me.

> Oh okay. Will adding it to the Executable Paths cause it to take precedence over other paths already in $PATH? Yes, it is prepended to PATH. > MinGW LDC is probably of fairly limited use... I imagine more MinGW users would want to use GDC? Seems more conventional to me. If you don't care about the runtime, MinGW seems your best bet on Win32.

I can't imagine a situation where I don't care about the runtime in my work :/ But sure, in the cases where you want to use MinGW, would you typically reach for GDC or LDC though?

> I can't imagine a situation where I don't care about the runtime in my work :/ If you don't build a large application, but just a small command line tool that you don't want to distribute, why bother? > But sure, in the cases where you want to use MinGW, would you typically reach for GDC or LDC though? GDC seems more natural, but LDC appears to be more up-to-date with latest dmd. Actually, I don't like all the dependencies that you get with MinGW. Every program seems to need a different version...

(In reply to Rainer Schuetze from comment #3) > It's LDC that is calling lib.exe, so probably the best Visual D can do is to > add the path to the VC bin folder to the "Executable Paths" by default. For > the mingw version of LDC, it cannot guess the path to the respective bin > folder, though. Okay, well I added the proper bin folder to the executable paths, and it worked as expected. I wonder if you can/should automatically add the path for the active version of VS? You already automate these paths for the users active version of VS in other cases right? (normal linking?)

I tweaked the defaults in https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1 and added browse buttons to set/add path entries. Visual D also tries to detect whether LDC is built for MSVC or MinGW environment, but I suspect that these should just be different compilers. You cannot really mix LDC for MinGW/32-bit and LDC for MSVC/64-bit, but these seem to be the current options.

(In reply to Rainer Schuetze from comment #9) > but I suspect that these should just be different compilers. This is true. Where do you think VisualD stands in defining different toolchains like this? We'll need a way to map 'platforms' to configured toolchains at some point. There are cross compilers for all sorts of architectures, and we don't really have a way to configure multiple toolchains for different targets with VisualD at this time. With Android and iOS coming online, I think this will be a critical issue fairly soon. I'm not sure the best approach. MS do it completely differently to VisualD. I often wonder if an MSBuild style solution would be more idiomatic?

> I'm not sure the best approach. MS do it completely differently to VisualD > I often wonder if an MSBuild style solution would be more idiomatic? This is available now in https://github.com/dlang/visuald/releases/tag/v0.44-beta2. LDC no longer supports MinGW, so no path confusions to that respect. So I'm closing this...