-fuse-ld with Mingw

Clang Frontend
1

Hello

I'm trying to use Clang to cross-compile for Windows on Linux. My system
linker (/usr/bin/ld) does not support the creation of Windows
executables, but I have another linker, x86_64-w64-mingw32-ld, that does.

There is logic in the Mingw support that prevents the use of any linker
that isn't called "ld" or "lld" which prevents me from using
x86_64-w64-mingw32-ld unless I revert the commit. This logic is added by
r253161 (4f60e73bd8c2ee40ef6d419e15860bfbfba4c619 in git). According to
the commit message, this was suggested by Filipe Cabecinhas.
Unfortunately, I don't have an email address, so I can't cc this
developer, however: would it be possible to revert this commit, as it
impedes the cross-compilation use case?

Many Thanks

2

+Yaron since he submitted r253161.

3

+Filipe Cabecinhas‏ <filcab@gmail.com‏>

Thanks for cc-ing me, I missed the message. Original discussion here:

http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151109/143190.html

I think r253161 could be reverted or made more flexible validating the linker name ends with “ld”.

Filipe, any thoughts?

4

I guess it shouldn't be a big problem. I always looked at -fuse-ld=...
as a "flavour" selector, to be paired with -B or $PATH or something.

But... Shouldn't x86_64-w64-mingw32-ld be found if you're using
x86_64-w64-mingw32 as the target triple?

GetProgramPath ends up calling generatePrefixedToolNames to do this.
Can you send us a reproducer for that problem?

  Filipe

5

Hello

Ah. You're right. Since the version I checked, the target triple does
select the ld (even if -fuse-ld can't choose anything other than ld or lld).

That works for my use-case, I guess.

Thanks