Possible mismatch between compiler-rt library naming and clang library search (on Linux)


One of our users recently (well, it is not that recent anymore)
reported that our clang install is unable to find compiler-rt libraries
on 32-bit x86. As I suspected, the problem is that our default CHOST is
i686-pc-linux-gnu, while the compiler-rt libraries are built with i386

I can easily reproduce this on multilib x86_64 system as well, using
the -target option:

  clang -v -m32 hello.c # works, uses i386
  clang -v -target i386-pc-linux-gnu # works
  clang -v -target i686-pc-linux-gnu # fails, looks for i686
  clang -v -target i586-pc-linux-gnu # fails, looks for i586

I think the relevant function is ToolChain::getCompilerRT() from
lib/Driver/ToolChain.cpp. It seems to use arch name straight from
the triple, with some special cases.

On the other hand, compiler-rt seems to allow only a few very specific

  set(X86 i386 i686)
  set(X86_64 x86_64)

while I don't know the rationale for allowing both i386 and i686, this
is certainly much narrower than what clang looks for.

Do you have any suggestions how we could improve this? I was thinking
of making the clang driver use Triple::getArchTypeName() rather than
the raw arch string but I don't know if I wouldn't break somebody's use

Alternatively, I could add compiler-rt symlinks for i486..i686 but that
seems like a very non-pretty solution. And clang seems to accept
triples up to i986.

Thanks in advance.

[1]:592964 – sys-devel/llvm-3.8.1-r2 - ../lib/linux/libclang_rt.builtins-i686.a: No such file or directory

Random question. Have you (or anyone) built compiler-rt for i686 and i386 and compared the outputs? Do we actually generate anything different between the two?

If not it seems to me we should teach clang to fall back to i386 if there isn’t a library that corresponds to the explicitly specified triple.

WRT compiler-rt’s build system code you pointed out, Petr Hosek has graciously picked up some of the work I started on cleaning up cross-compiling and multi-arch targeting for compiler-rt. I would strongly suggest you check out his patches. I’ll list the two most interesting ones below.


As people start exercising his patches we will likely start hitting issues in both compiler-rt’s build system and the clang driver because they both have an excess of strange magic. I’d really like to see us converge the two of them into a single convention so that we can get rid of as much of the magic as possible.