Cross-compiling with Clang and LLD fails trying to call GCC


I'm one of the developers of the Haiku operating system [1]. Currently
we use GCC (7.3), however, there has been ongoing work by myself and a
few others to add support for building with Clang.

The Linux box I've been attempting this on does not have any GCC
installed at all, neither Ubuntu's GCC nor our cross-tools GCC. But
when I get to the first link that uses Clang instead of LLD directly
(most kernel-related things invoke the linker directly), this happens:

clang: error: unable to execute command: Executable "gcc" doesn't exist!
clang: error: linker (via gcc) command failed with exit code 1 (use -v
to see invocation)

The full invocation and output of clang -v can be seen at [2], along
with a list of all the linkers in /usr/bin.

As you can see, we're not using --gcc-toolchain in invoking Clang, but
instead are using -nostdlib and adding the glue code and standard
libraries to the invocation manually (we do the same when using
cross-GCC), as well as -fuse-ld=lld; so there really isn't any reason
Clang should be trying to call GCC here, as far as I can tell.

The same thing occurs on a "true" cross-compile, i.e. x86_64->ARM, so
this isn't arch-specific.



Hello Waddlesplash,

I have a suspicion that this may be down to how the Haiku toolchain is
implemented in clang for -target x86_64-unknown-haiku . Taking a brief
look in llvm/tools/clang/lib/Driver/Toolchains/Haiku.cpp and tracing
the inherited classes back through to Generic_ELF and Generic_GCC it
looks like the buildLinker is using tools::gcc::Linker() which looks
like it will always call gcc as the linker driver. The Linux toolchain
uses tools::gnutools::Linker() which does call ld directly. It may be
possible that -fuse-ld=lld isn't supported with the way the Haiku
driver is implemented.

I haven't checked this out beyond a few minutes of searching, but it
may be worth taking a look at that part of the clang code yourself to
confirm. I've often found when cross-compiling it is often best to go
back to the ToolChain class for my target when it isn't behaving like
I'd expect.

Good luck.


There is a fallback toolchain implementation that depends on GCC for
linking. You are very likely hitting that one.


Ah, indeed, that is the issue. Thanks for the tip!