Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 651908 - sys-devel/clang should create ${CHOST}-clang & co symlinks based on LLVM_TARGETS
Summary: sys-devel/clang should create ${CHOST}-clang & co symlinks based on LLVM_TARGETS
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: LLVM support project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-29 11:48 UTC by Alexis Ballier
Modified: 2020-12-22 20:42 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexis Ballier gentoo-dev 2018-03-29 11:48:18 UTC
[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.
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-03-29 12:25:30 UTC
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.
Comment 2 Alexis Ballier gentoo-dev 2018-03-29 14:18:35 UTC
(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
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-04-07 08:43:52 UTC
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.
Comment 4 Andrew Aladjev 2020-01-27 21:08:32 UTC
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.
Comment 5 Andrew Aladjev 2020-02-05 19:50:37 UTC
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.