[win] lld-link shouldn't depend on env vars to find libraries optionally

[Quuxplusone]

Bugzilla Link	PR24616
Status	CONFIRMED
Importance	P normal
Reported by	Nico Weber (nicolasweber@gmx.de)
Reported on	2015-08-28 13:42:34 -0700
Last modified on	2018-09-19 15:27:03 -0700
Version	unspecified
Hardware	PC All
CC	ikudrin@accesssoftek.com, llvm-bugs@lists.llvm.org, rafael@espindo.la, rnk@google.com, ruiu@google.com
Fixed by commit(s)
Attachments
Blocks	PR38967
Blocked by
See also	PR24741

With clang-cl, I can do

> clang-cl -c file.cc -m32
> clang-cl -c file.cc -m64

in the same terminal session without running vsvars and that works fine.

It'd be awesome if I could then say

> lld-link file.obj -m32
> lld-link file.obj -m64

and have it produce a 32-bit / 64-bit executable respectively.

[Quuxplusone]

link.exe (and lld-link) has an option /machine for that purpose. Try /machine:x86 or /machine:x64.

[Quuxplusone]

Does it modify the library search path from LIB, though?

[Quuxplusone]

No it doesn't. But how can you find a correct search path if no path is given via the environment variable? What does clang-cl do?

[Quuxplusone]

(In reply to comment #3)
> No it doesn't. But how can you find a correct search path if no path is
> given via the environment variable? What does clang-cl do?

INCLUDE doesn't depend on the target architecture, so we're just getting lucky.

Nico, personally I feel like if the user has LIB set then we have to trust it.
It's what link.exe does. We can do whatever we want when LIB isn't set, though.

Clang currently tries to guess which version of VS you want and which Windows
SDK you're using if INCLUDE isn't set. The code and the guesses are pretty bad,
but we could make it better and share it with LLD.

Users have already hit issues with the Windows 10 SDK paths being stale, for
example:
http://lists.llvm.org/pipermail/llvm-dev/2015-August/089011.html

[Quuxplusone]

(In reply to comment #4)
> (In reply to comment #3)
> > No it doesn't. But how can you find a correct search path if no path is
> > given via the environment variable? What does clang-cl do?
>
> INCLUDE doesn't depend on the target architecture, so we're just getting
> lucky.

Some stuff does depend on the target arch. Rui: See
MSVCToolChain::getVisualStudioBinariesFolder() in
tools/clang/lib/Driver/MSVCToolChain.cpp for example (and other stuff in that
file).

We probably want to lift some of that into LLVM.

> Nico, personally I feel like if the user has LIB set then we have to trust
> it. It's what link.exe does. We can do whatever we want when LIB isn't set,
> though.

Yes, that's what I mean.

[Quuxplusone]

> Some stuff does depend on the target arch. Rui: See
> MSVCToolChain::getVisualStudioBinariesFolder() in
> tools/clang/lib/Driver/MSVCToolChain.cpp for example (and other stuff in
> that file).
>
> We probably want to lift some of that into LLVM.

At first that looked hacky to me, but it would be undeniably convenient. I
agree that we probably should do this by moving the code from Clang to LLVM and
using it in LLD.

[Quuxplusone]

Please take a look at my changes regarding using of Universal CRT: http://reviews.llvm.org/D12695. I think I can make the same changes for lld-link.

[Quuxplusone]

(looks like this was started here http://reviews.llvm.org/D12604 . that cl looks stalled atm)

[Quuxplusone]

ruiu: Ping :-)

[Quuxplusone]

quarterly ping

[Quuxplusone]

Moving to more specific "COFF" component (instead of LLD's "All Bugs").

[Quuxplusone]

ruiu: Would you be interested in finishing https://reviews.llvm.org/D12604 and making lld call that code if LIB isn't set?

[Quuxplusone]

I don't remember why I abandoned it, but looks like we need it. I'll resurrect it.

[Quuxplusone]

How are the resurrection efforts coming along? :-)

[Quuxplusone]

Sorry there's no progress for this bug, and I don't think I have time to work on this this week or next week. Feel free to take this if you want.