Bug 580870 – llvm-runtimes/compiler-rt: various compiler_rt libs should be produced for all appropriate targets

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description SpanKY 2016-04-22 19:49:19 UTC]

when llvm itself builds, it supports a ton of targets beyond the native one.  e.g.:
  $ clang -target arm-linux-gnueabihf -c test.c
  $ file test.o
  test.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (GNU/Linux), not stripped

when you try to build with some of the sanitizers though, it fails because the supplemental libs aren't included:
  $ clang -target arm-linux-gnueabihf test.c -fsanitize=address,undefined
/usr/bin/ld: error: cannot open /usr/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.asan-arm.a: No such file or directory

the native ones are included though:
  libclang_rt.asan-i386.a
  libclang_rt.asan-x86_64.a

can we update the llvm ebuild to build all of the ones that are feasible ?

[Comment 1 Michał Górny 2016-04-22 20:29:52 UTC]

Do you happen to know how?

[Comment 2 SpanKY 2016-04-22 21:26:29 UTC]

we're looking at it in https://crbug.com/604877, but i'm not familiar enough with the llvm build system to provide useful thoughts/opinions

i do want to make sure we agree that this behavior/feature is desirable if it's feasible.  otherwise, we'll need to debate/figure out an alternative.  i think the llvm world has been trying to avoid the general GNU flow where you need a unique toolchain for every single target variation.

[Comment 3 Michał Górny 2016-04-23 05:46:51 UTC]

Yes, it is desirable. Does it require multitarget support enabled in binutils?

[Comment 4 SpanKY 2016-04-23 06:44:09 UTC]

i'd assume clang would be using its own built in assembler.  when i run clang as in comment #0, it doesn't seem to be execing any other program.  and my native binutils are not built w/multitarget enabled.

[Comment 5 Michał Górny 2016-04-23 07:02:53 UTC]

Well, I was thinking more in terms of ranlib or something like that.

[Comment 6 SpanKY 2016-04-23 08:34:04 UTC]

for GNU binutils, i wouldn't worry about ar/ranlib behavior.  there shouldn't be any target-specific behavior in there.  the portability issues we've seen in Gentoo with those tools have largely been in Gentoo/Prefix land where the native `ar` & `ranlib` tools were a bit ... anemic.