[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.
Note that the list of CHOSTS in Comment 3 is incomplete, since for older 32-bit x86 CPUs you might have to override the profile CHOST to one of: i486-pc-linux-gnu i586-pc-linux-gnu (Gentoo still provides a stage3 built with an i486 CHOST for bootstrapping legacy systems) See Bug 662108 where I run into the problem that clang doesn't install symlinks for the i586- prefixed build tools on my pre-pentium-pro x86 system.
sys-devel/llvm-toolchain-symlinks virtual/llvm-crossdev-arm64-symlinks etc llvm_targets_AArch64 or alike cross build targets as a use req.. virtual/cross-rust..... same https://github.com/mstorsjo/llvm-mingw windows arm64 etc toolchains exist.. crossdev using these as bin/s whom knows.. one could set virtual perhaps sure sys-devel/llvm-toolchain-symlinks as a rehashed gets redundant over ??? N profiles but could get the job done and user can emerge virtual/llvm-crossdev-arm64-symlinks virtual/llvm-crossdev-arm7hf-symlinks etc sure it might rebuild llvm/clang but for novices wont need to keep stuffing package.use or make.conf etc.. llvm-symlinks could be morphed into various virtual/s for crossdev to do the same for clang crossdev targets just a though.. upgrading clang minor version/s wont have to worry about breakages.... perhaps..
