[ebuild R ] sys-devel/clang-6.0.0-r1:6::gentoo USE="default-compiler-rt default-libcxx static-analyzer -debug -doc {-test} -xml (-z3)" ABI_X86="32 (64) (-x32)" LLVM_TARGETS="AArch64 AMDGPU ARM BPF Hexagon Lanai MSP430 Mips NVPTX PowerPC Sparc SystemZ (X86) XCore" PYTHON_TARGETS="python2_7" 0 KiB But I only have x86 & amd64 symlinks in /usr/lib/llvm/6/bin/ As a consequence, e.g., compiler-rt-sanitizers fails to cross compile with: -- Found assembler: aarch64-unknown-linux-gnu-clang CMake Error at CMakeLists.txt:10 (project): The CMAKE_C_COMPILER: aarch64-unknown-linux-gnu-clang is not a full path and was not found in the PATH. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH.
Didn't we discuss this already? I think I said I'm fine with this but someone needs to make a LLVM_TARGET -> CHOST mapping list.
(In reply to Michał Górny from comment #1) > Didn't we discuss this already? I think I said I'm fine with this but > someone needs to make a LLVM_TARGET -> CHOST mapping list. yeah it was for tracking purposes and gathering ideas on how to implement this
All CHOSTs currently present in our profiles (96): aarch64-gentoo-linux-musl aarch64-unknown-linux-gnu aarch64_be-unknown-linux-gnu alpha-unknown-linux-gnu arm-unknown-linux-gnu arm-unknown-linux-musleabi arm-unknown-linux-uclibc armv4l-unknown-linux-gnu armv4tl-softfloat-linux-gnueabi armv5tel-softfloat-linux-gnueabi armv6j-hardfloat-linux-gnueabi armv6j-hardfloat-linux-uclibceabi armv7a-hardfloat-linux-gnueabi armv7a-hardfloat-linux-musleabi armv7a-hardfloat-linux-uclibceabi armv7a-softfloat-linux-gnueabi hppa-unknown-linux-gnu i386-pc-solaris2.10 i386-pc-solaris2.11 i586-pc-winnt3.5 i586-pc-winnt5.2 i586-pc-winnt6.0 i586-pc-winnt6.1 i686-apple-darwin10 i686-apple-darwin11 i686-apple-darwin12 i686-apple-darwin13 i686-apple-darwin14 i686-apple-darwin15 i686-apple-darwin16 i686-apple-darwin17 i686-apple-darwin8 i686-apple-darwin9 i686-gentoo-freebsd11.1 i686-gentoo-freebsd9.1 i686-gentoo-linux-musl i686-gentoo-linux-uclibc i686-pc-cygwin i686-pc-linux-gnu ia64-unknown-linux-gnu m68k-atari-mint m68k-unknown-linux-gnu mips-gentoo-linux-musl mips-gentoo-linux-uclibc mips-unknown-linux-gnu mips64-unknown-linux-gnu mips64-unknown-linux-gnuabi64 mips64-unknown-linux-gnuabin32 mips64el-unknown-linux-gnu mips64el-unknown-linux-gnuabi64 mips64el-unknown-linux-gnuabin32 mipsel-gentoo-linux-musl mipsel-gentoo-linux-uclibc mipsel-unknown-linux-gnu powerpc-apple-darwin8 powerpc-apple-darwin9 powerpc-gentoo-linux-musl powerpc-gentoo-linux-uclibc powerpc-ibm-aix5.2.0.0 powerpc-ibm-aix5.3.0.0 powerpc-ibm-aix6.1.0.0 powerpc-ibm-aix7.1.0.0 powerpc-ibm-aix7.2.0.0 powerpc-unknown-linux-gnu powerpc64-pc-linux-gnu powerpc64-unknown-linux-gnu powerpc64le-unknown-linux-gnu s390-ibm-linux-gnu s390x-ibm-linux-gnu sh-unknown-linux-gnu sparc-sun-solaris2.10 sparc-sun-solaris2.11 sparc-sun-solaris2.9 sparc-unknown-linux-gnu sparc64-unknown-linux-gnu sparcv9-sun-solaris2.10 sparcv9-sun-solaris2.11 x86_64-apple-darwin10 x86_64-apple-darwin11 x86_64-apple-darwin12 x86_64-apple-darwin13 x86_64-apple-darwin14 x86_64-apple-darwin15 x86_64-apple-darwin16 x86_64-apple-darwin17 x86_64-apple-darwin9 x86_64-gentoo-freebsd11.1 x86_64-gentoo-freebsd9.1 x86_64-gentoo-linux-musl x86_64-gentoo-linux-muslx32 x86_64-gentoo-linux-uclibc x86_64-pc-cygwin x86_64-pc-linux-gnu x86_64-pc-linux-gnux32 x86_64-pc-solaris2.10 x86_64-pc-solaris2.11 One thing to note in particular is how to handle targets where CHOST includes system version.
Hello. This is a big problem for arm. "arm-unknown-linux-gnu" is not a valid CHOST for gcc. It will throw "Configuration arm-unknown-linux-gnu not supported". So you will have to use "arm-unknown-linux-gnueabi" instead. But you won't be able to compile "compiler-rt-sanitizers" because clang will create "arm-unknown-linux-gnu-gcc" for you without "eabi" suffix. So there are 2 possible fixes: allow "gnu" for gcc or allow "gnueabi" for clang.
I've found the following code: # now create target symlinks for all supported ABIs for abi in $(get_all_abis); do local abi_chost=$(get_abi_CHOST "${abi}") for i in "${clang_tools[@]}"; do dosym "${i}-${clang_version}" \ "/usr/lib/llvm/${SLOT}/bin/${abi_chost}-${i}-${clang_version}" dosym "${abi_chost}-${i}-${clang_version}" \ "/usr/lib/llvm/${SLOT}/bin/${abi_chost}-${i}" done done This code is good but it is possible for ABI to have multiple CHOSTS and it is not possible to list them all. So workaround can be the following: # now create target symlinks for all supported ABIs + default CHOSTs and current ABI + current CHOST for ... done for i in "${clang_tools[@]}"; do dosym "${i}-${clang_version}" \ "/usr/lib/llvm/${SLOT}/bin/${CHOST}-${i}-${clang_version}" dosym "${CHOST}-${i}-${clang_version}" \ "/usr/lib/llvm/${SLOT}/bin/${CHOST}-${i}" done But is is not the right way, just workaround. ----- I think the right way will be not to use "get_abi_CHOST" here. It is possible to replace all "get_abi_CHOST" with "get_abi_default_CHOST", because it is really just default one, so people wont be confused by its name. It will be good to have separate "replace_abi_in_CHOST" function that will properly replace for example "arm64-unknown-linux-gnueabi" with "arm-unknown-linux-gnueabi". Pseudo example: local abi_chost=$(replace_abi_in_CHOST "${CHOST}" "${abi}") for i in "${clang_tools[@]}"; do ... done Please assign this bug to core gentoo developers, regular users can't fix it, fix requires deep understanding of current eclasses.
