Before I start to explain this - do we all agree that first of all the host has to have sys-devel/binutils with USE="multitarget" installed, and that crossdev -S armv7a-unkown-linux-gnueabihf with USE="-multitarget" for cross-binutils is the proper way to setup a cross-compile toolchain? Ok, here's the problem: using emerge-armv7a-unknown-hardfloat-gnueabihf, or whatever your desired target may be, is a pure joy for a target as @system. Only python stuff is a bit whacky. However, it fails for the case of llvm with an error which seeems to be related to llvm-config perhaps? [106/113] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o [107/113] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/YAMLParser.cpp.o [108/113] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Program.cpp.o [109/113] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o [110/113] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Path.cpp.o [111/113] Building CXX object tools/llvm-config/CMakeFiles/llvm-config.dir/llvm-config.cpp.o [112/113] Linking CXX static library lib/libLLVMSupport.a [113/113] Linking CXX executable bin/llvm-config FAILED: bin/llvm-config : && /usr/bin/armv7a-unknown-linux-gnueabihf-g++ -O2 -pipe -fomit-frame-pointer -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -ffunction-sections -fdata-sections -O3 -DNDEBUG -Wl,-O1 -Wl,--as-needed -Wl,-allow-shlib-undefined -Wl,-rpath-link,/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/sys-devel/llvm-6.0.1/work/llvm-6.0.1.src-.arm/NATIVE/./lib -Wl,-O3 -Wl,--gc-sections tools/llvm-config/CMakeFiles/llvm-config.dir/llvm-config.cpp.o -o bin/llvm-config -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a -lpthread -lz -lrt -ldl -lcurses -lpthread -lm lib/libLLVMDemangle.a && : lib/libLLVMSupport.a: error adding symbols: Archive has no index; run ranlib to add one collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. I'll add the full build log
Created attachment 547952 [details] compressed build.log this is for llvm-6.0.1, but it's the same error for llvm-6.0.1-r1
Created attachment 547954 [details] output of emerge --info this is the emerge --info from the host
these are the useflags for the host cross compiler: [ebuild R ~] cross-armv7a-unknown-linux-gnueabihf/binutils-2.30-r4:2.30::own USE="cxx nls -doc -multitarget -static-libs -test" 0 KiB [ebuild R ] cross-armv7a-unknown-linux-gnueabihf/glibc-2.26-r7:2.2::own USE="-audit -caps -debug -doc -gd -hardened -headers-only -multilib -nscd -profile (-selinux) -suid -systemtap -vanilla" 0 KiB cross-armv7a-unknown-linux-gnueabihf/gcc-7.3.0-r5:7.3.0::own USE="cxx fortran nls nptl openmp pch pie sanitize ssp (-altivec) -cilk -debug -doc (-fixed-point) -go -graphite -hardened -jit -libssp -mpx -multilib -objc -objc++ -objc-gc -pgo -regression-test -vanilla -vtv" 0 KiB these are the useflags for the hosts sys-devel/binutils: [ebuild R ] sys-devel/binutils-2.30-r2:2.30::gentoo USE="cxx multitarget nls -doc -static-libs -test" 0 KiB If it matters, I have included ARM into LLVM_TARGETS on the machine: [ebuild R ~] sys-devel/llvm-6.0.1-r1:6::gentoo USE="gold libffi ncurses xml -debug -doc -libedit -test -xar" ABI_X86="32 (64) (-x32)" LLVM_TARGETS="AMDGPU ARM (X86) -AArch64 -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -Sparc -SystemZ -XCore" 0 KiB
First of all, I've never enabled USE="multitarget" and I didn't even know what it did until now. I gather it allows your "native" binutils to target every supported CPU and OS combination. In practise, this would not be used when building our packages because your cross gcc will use your cross binutils and not touch your native binutils at all. Regarding the Python stuff, I have done good work on that but it's not quite ready yet. I'm not convinced that the LLVM problem is cross-related. I found a similar report here although it doesn't look like you've explicitly enabled LTO anywhere. https://bugs.llvm.org/show_bug.cgi?id=35153
Did you try LLVM 7 yet? I just cross-built it for ARM with no problems.
@Chewi, could you test without -DLLVM_TABLEGEN, please? I think this should be unnecessary, and it would be helpful to confirm that.
(In reply to Michał Górny from comment #6) > @Chewi, could you test without -DLLVM_TABLEGEN, please? I think this should > be unnecessary, and it would be helpful to confirm that. That's still required but it would be good to solve that the other way. /bin/sh: /var/tmp/portage/sys-devel/llvm-7.0.0/work/llvm-7.0.0.src-.arm/NATIVE/bin/llvm-tblgen: cannot execute binary file: Exec format error
I'm guessing you need to tell CMake about the native compiler somehow ;-).
@Chewi no I haven't, actually got stuck with llvm:6 for the last couple of days. But I may try straight away. Could you please post your hosts emerge --info and useflags for binutils, cross-binutils and cross-gcc?
Created attachment 548002 [details] Chewi's build info Here you go.
Created attachment 548004 [details] output of emerge --info You don't seems to have nls in your cross compiler, don't use multitarget for the system-binutils and are on unstable glibc/gcc. Is 2.30-r2 your active binutils, since you're having 2.31.1 as well? The ebuilds are the usual symlinks to the tree from an overlay, no modification, right? [ebuild R ] sys-devel/binutils-2.30-r2:2.30::gentoo USE="cxx multitarget nls -doc -static-libs -test" 0 KiB [ebuild R ~] cross-armv7a-unknown-linux-gnueabihf/binutils-2.30-r4:2.30::own USE="cxx nls -doc -multitarget -static-libs -test" 0 KiB [ebuild R ~] cross-armv7a-unknown-linux-gnueabihf/gcc-7.3.0-r5:7.3.0::own USE="cxx fortran nls nptl openmp pch pie sanitize ssp (-altivec) -cilk -debug -doc (-fixed-point) -go -graphite -hardened -jit -libssp -mpx -multilib -objc -objc++ -objc-gc -pgo -regression-test -vanilla -vtv" 0 KiB Needless to say that my cross-emerge of llvm-7 failed with the same error. And I had to emerge llvm-7 on my hosts machine first, for llvm-tblgen. And even though I kind of like the idea to get rid of it, the llvm/clang cross-compile reference states that tblgen-llvm (from the host) is mandantory, and both tblgen-clang + tblgen-llvm to cross-compile clang. https://llvm.org/docs/HowToCrossCompileLLVM.html The different sys-gcc and sys-glibc shouldn't be relevant. So guess I'm going to flipp around some useflags of my crossdev toolchain, but won't make it before the weekend for results to share.
(In reply to tt_1 from comment #11) > You don't seems to have nls in your cross compiler, don't use multitarget > for the system-binutils and are on unstable glibc/gcc. Is 2.30-r2 your > active binutils, since you're having 2.31.1 as well? The ebuilds are the > usual symlinks to the tree from an overlay, no modification, right? nls is irrelevant. I would definitely disable multitarget, it would not surprise me if that were the issue. I did realise as I was generating that info that I hadn't yet selected the latest installed. Now fixed. :) Although I do some strange things in my cross-boss project, what you see here is plain crossdev and toolchain packages with no modifications or hacks.
So yeah, I was able to cross-emerge =llvm-6.0.1-r1 for armv7a as I removed the multitarget useflag from sys-devel/binutils. Shall I open a new bug for sys-devel/binutils then? We may continue our discussion about llvm-tblegen here?
(In reply to tt_1 from comment #13) > So yeah, I was able to cross-emerge =llvm-6.0.1-r1 for armv7a as I removed > the multitarget useflag from sys-devel/binutils. Woo! > Shall I open a new bug for sys-devel/binutils then? I doubt the problem is with binutils itself. It may be specific to llvm or it could affect many more packages, how many have you tried? If it's the latter, it probably isn't worth fixing and we should clarify the multitarget USE flag description. > We may continue our discussion about llvm-tblegen here? May as well.
this is confusing: llvm fails to build with USE=gold, but there are two errors - one if binutils is built with USE="-multitarget", and another on if binutils is built with USE="multitarget" since all USE="gold" does is adding a second include directory: -DLLVM_BINUTILS_INCDIR="/"${EPREFIX}/usr/include" I wonder if there is some sort of missmatch going on. I'll upload logs within a few days, too busy at the moment.
I just learnt that the symlinks for libbfd and libopcodes libararies are slightly different, to reflect abi breakage. Does this mean, the cross-binutils built by crossdev, the hosts binutils and possibly the cross-emerged binutils in /usr/armv7a-unknown-linux-gnueabihf/ should be in sync? its either: libbfd-2.30.0.gentoo-sys-devel-binutils-st.so libopcodes-2.30.0.gentoo-sys-devel-binutils-st.so or: libbfd-2.30.0.gentoo-sys-devel-binutils-mt.so libopcodes-2.30.0.gentoo-sys-devel-binutils-mt.so
I tried to sync the multitarget use flag: hosts binutils+binutils-libs: +multitarget crossdev toolchain binutils: +multitarget cross-emerged binutils-libs: +multitarget but it still fails the same way, and works if all is reverted to -multitarget.
I can't reproduce anymore with current llvm-9
