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 ?
Do you happen to know how?
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.
Yes, it is desirable. Does it require multitarget support enabled in binutils?
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.
Well, I was thinking more in terms of ranlib or something like that.
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.
