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?
+Yaron since he submitted r253161.
+Filipe Cabecinhas <firstname.lastname@example.org>
Thanks for cc-ing me, I missed the message. Original discussion here:
I think r253161 could be reverted or made more flexible validating the linker name ends with “ld”.
Filipe, any thoughts?
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?
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.