Tries to use /usr/lib64/libc_nonshared.a instead of library from prefix, as shown below: >>> Emerging (4 of 297) sys-libs/compiler-rt-5.0.1::gentoo * compiler-rt-5.0.1.src.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking compiler-rt-5.0.1.src.tar.xz to /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/var/tmp/portage/sys-libs/compiler-rt-5.0.1/work >>> Source unpacked in /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/var/tmp/portage/sys-libs/compiler-rt-5.0.1/work >>> Preparing source in /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/var/tmp/portage/sys-libs/compiler-rt-5.0.1/work/compiler-rt-5.0.1.src ... >>> Source prepared. >>> Configuring source in /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/var/tmp/portage/sys-libs/compiler-rt-5.0.1/work/compiler-rt-5.0.1.src ... >>> Working in BUILD_DIR: "/cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/var/tmp/portage/sys-libs/compiler-rt-5.0.1/work/compiler-rt-5.0.1_build" cmake -C /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/var/tmp/portage/sys-libs/compiler-rt-5.0.1/work/compiler-rt-5.0.1_build/gentoo_common_config.cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr -DCOMPILER_RT_INSTALL_PATH=/cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/lib/clang/5.0.1 -DCOMPILER_RT_INCLUDE_TESTS=no -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_USER_MAKE_RULES_OVERRIDE=/cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/var/tmp/portage/sys-libs/compiler-rt-5.0.1/work/compiler-rt-5.0.1_build/gentoo_rules.cmake -DCMAKE_TOOLCHAIN_FILE=/cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/var/tmp/portage/sys-libs/compiler-rt-5.0.1/work/compiler-rt-5.0.1_build/gentoo_toolchain.cmake /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/var/tmp/portage/sys-libs/compiler-rt-5.0.1/work/compiler-rt-5.0.1.src loading initial cache file /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/var/tmp/portage/sys-libs/compiler-rt-5.0.1/work/compiler-rt-5.0.1_build/gentoo_common_config.cmake -- The C compiler identification is Clang 5.0.1 -- The CXX compiler identification is Clang 5.0.1 -- The ASM compiler identification is unknown -- Found assembler: /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/lib/llvm/5/bin/x86_64-pc-linux-gnu-clang -- Check for working C compiler: /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/lib/llvm/5/bin/x86_64-pc-linux-gnu-clang -- Check for working C compiler: /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/lib/llvm/5/bin/x86_64-pc-linux-gnu-clang -- broken CMake Error at /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/share/cmake/Modules/CMakeTestCCompiler.cmake:52 (message): The C compiler "/cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/lib/llvm/5/bin/x86_64-pc-linux-gnu-clang" is not able to compile a simple test program. It fails with the following output: Change Dir: /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/var/tmp/portage/sys-libs/compiler-rt-5.0.1/work/compiler-rt-5.0.1_build/CMakeFiles/CMakeTmp Run Build Command:"/cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/ninja" "cmTC_97c30" [1/2] Building C object CMakeFiles/cmTC_97c30.dir/testCCompiler.c.o [2/2] Linking C executable cmTC_97c30 FAILED: cmTC_97c30 : && /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/lib/llvm/5/bin/x86_64-pc-linux-gnu-clang -O2 -pipe -O2 -pipe -Wl,-O1 -Wl,--as-needed -nodefaultlibs -lc CMakeFiles/cmTC_97c30.dir/testCCompiler.c.o -o cmTC_97c30 -Wl,-rpath,/cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/x86_64-pc-linux-gnu/lib/gcc:/cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/x86_64-pc-linux-gnu/lib:/cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/lib64:/cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/lib64 && : /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: cannot find crt1.o: No such file or directory /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: cannot find crti.o: No such file or directory /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: cannot find crtbegin.o: No such file or directory /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: cannot find /usr/lib64/libc_nonshared.a clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:14 (project) -- Configuring incomplete, errors occurred!
Actually, the problem seems to be with clang itself: $ echo 'int main() { return 0; }' >| test.c $ clang test.c /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: cannot find crt1.o: No such file or directory /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: cannot find crti.o: No such file or directory /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: cannot find crtbegin.o: No such file or directory /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: cannot find -lgcc /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: cannot find /usr/lib64/libc_nonshared.a clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) $ clang --gcc-toolchain=${EPREFIX}/usr test.c $ echo $? 0
This sounds related to https://bugs.gentoo.org/502318
(In reply to Fabian Groffen from comment #2) > This sounds related to https://bugs.gentoo.org/502318 Indeed. Feel free to close this as a duplicate.
(In reply to Guilherme Amadio from comment #1) > Actually, the problem seems to be with clang itself: > > $ echo 'int main() { return 0; }' >| test.c > $ clang test.c > /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: > cannot find crt1.o: No such file or directory > /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: > cannot find crti.o: No such file or directory > /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: > cannot find crtbegin.o: No such file or directory > /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: > cannot find -lgcc > /cvmfs/sft.cern.ch/lcg/contrib/gentoo/linux/usr/bin/x86_64-pc-linux-gnu-ld: > cannot find /usr/lib64/libc_nonshared.a > clang-5.0: error: linker command failed with exit code 1 (use -v to see > invocation) > $ clang --gcc-toolchain=${EPREFIX}/usr test.c > $ echo $? > 0 I see some similar problems here. But for me they don't go away with just adding the --gcc-toolchain option. Without the option: $ cat test.cpp #include <iostream> using namespace std; int main(int argc, char **argv) { return 0; } $ clang -std=gnu++14 -v -c -o test.o test.cpp clang version 6.0.0 (tags/RELEASE_600/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /home/mageta/local/gentoo/usr/lib/llvm/6/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8.4 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 "/home/mageta/local/gentoo/usr/lib64/llvm/6/bin/clang-6.0" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v -coverage-notes-file /home/mageta/tmp/test.gcno -resource-dir /home/mageta/local/gentoo/usr/lib64/llvm/6/bin/../../../../lib/clang/6.0.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward -internal-isystem /usr/local/include -internal-isystem /home/mageta/local/gentoo/usr/lib64/llvm/6/bin/../../../../lib/clang/6.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=gnu++14 -fdeprecated-macro -fdebug-compilation-dir /home/mageta/tmp -ferror-limit 19 -fmessage-length 136 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c++ test.cpp clang -cc1 version 6.0.0 based upon LLVM 6.0.0 default target x86_64-pc-linux-gnu ignoring nonexistent directory "/include" ignoring duplicate directory "/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward /usr/local/include /home/mageta/local/gentoo/usr/lib64/llvm/6/bin/../../../../lib/clang/6.0.0/include /usr/include/x86_64-linux-gnu /usr/include End of search list. So this is obviously using the wrong GCC installation. With the option: $ clang -std=gnu++14 --gcc-toolchain=${HOME}/local/gentoo/usr -v -o test test.cpp clang version 6.0.0 (tags/RELEASE_600/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /home/mageta/local/gentoo/usr/lib/llvm/6/bin Found candidate GCC installation: /home/mageta/local/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0 Found candidate GCC installation: /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0 Selected GCC installation: /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0 Candidate multilib: .;@m64 Selected multilib: .;@m64 "/home/mageta/local/gentoo/usr/lib64/llvm/6/bin/clang-6.0" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v -resource-dir /home/mageta/local/gentoo/usr/lib64/llvm/6/bin/../../../../lib/clang/6.0.0 -internal-isystem /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7 -internal-isystem /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/x86_64-pc-linux-gnu -internal-isystem /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/backward -internal-isystem /usr/local/include -internal-isystem /home/mageta/local/gentoo/usr/lib64/llvm/6/bin/../../../../lib/clang/6.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=gnu++14 -fdeprecated-macro -fdebug-compilation-dir /home/mageta/tmp -ferror-limit 19 -fmessage-length 273 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-7ec93f.o -x c++ test.cpp clang -cc1 version 6.0.0 based upon LLVM 6.0.0 default target x86_64-pc-linux-gnu ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7 /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/x86_64-pc-linux-gnu /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/backward /usr/local/include /home/mageta/local/gentoo/usr/lib64/llvm/6/bin/../../../../lib/clang/6.0.0/include /usr/include/x86_64-linux-gnu /usr/include End of search list. "/home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld" -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64/crt1.o /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64/crti.o /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/crtbegin.o -L/home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0 -L/home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64 -L/home/mageta/local/gentoo/usr/lib64/llvm/6/bin/../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/lib -L/home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/../../.. -L/lib -L/usr/lib /tmp/test-7ec93f.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/crtend.o /home/mageta/local/gentoo/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64/crtn.o /tmp/test-7ec93f.o: In function `__cxx_global_var_init': test.cpp:(.text.startup+0x13): undefined reference to `std::ios_base::Init::Init()' test.cpp:(.text.startup+0x19): undefined reference to `std::ios_base::Init::~Init()' clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation) That doesn't seem to work either. And it still uses '/lib64/ld-linux-x86-64.so.2', and some other paths from the base-system - especially during the linking step -, which it shouldn't.
Hi I am trying to understand why clang is needed for GNU/Linux targets. Hints?
"needed" is a big word, but clang/llvm has a nifty featureset someone might be very interested in (such as tsan/asan or superclear coloured error messages in the past)
(In reply to Benda Xu from comment #5) > Hi I am trying to understand why clang is needed for GNU/Linux targets. > Hints? Well, I just want to use it to compile things :-) I am not using it as system compiler for prefix, I just need it as a user to compile code I work on.
(In reply to Benda Xu from comment #5) > Hi I am trying to understand why clang is needed for GNU/Linux targets. > Hints? Why would you not? You can use the static analyzer. It compiles C++ faster than G++ to date - AFAIK. It provides some very convenient tools like clang-format, clang-tidy, ... It has a good feature set and additionally, if you develop something you might want to make sure it not just compiles with GCC to not have a vendor lock-in. Its a valid package to have, and to use, also on Linux.
Thanks guys. We did a dirty hack to gcc for it to look for all the libc objects inside EPREFIX. https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/features/prefix/standalone/profile.bashrc#n9 sys-devel/clang would require a similar treatment.
As a workaround for merging packages, I've been using: $ CFLAGS=--gcc-toolchain=$EPREFIX/usr \ CXXFLAGS=--gcc-toolchain=$EPREFIX/usr emerge $PACKAGES
Sigh, I was using EXTRA_ECONF and that's why my fix didn't work. What we need for prefix is to add -DGCC_INSTALL_PREFIX=${EPREFIX}/usr to cmake for clang. @mgorny: Can I do that, or do you see any problems? I tested with clang-5.0 to 7.0, and now it works without any extra options.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fe687c9d5a1b80711081933b86da2624259b7b3a commit fe687c9d5a1b80711081933b86da2624259b7b3a Author: Guilherme Amadio <amadio@gentoo.org> AuthorDate: 2018-03-19 18:31:11 +0000 Commit: Guilherme Amadio <amadio@gentoo.org> CommitDate: 2018-03-20 06:28:43 +0000 sys-devel/clang: fix for prefix, bug 649732 Closes: https://bugs.gentoo.org/649732 Package-Manager: Portage-2.3.24, Repoman-2.3.6 sys-devel/clang/clang-4.0.1.ebuild | 8 +++++++- sys-devel/clang/clang-5.0.1.ebuild | 6 ++++++ sys-devel/clang/clang-6.0.0.ebuild | 6 ++++++ sys-devel/clang/clang-6.0.9999.ebuild | 6 ++++++ sys-devel/clang/clang-9999.ebuild | 6 ++++++ 5 files changed, 31 insertions(+), 1 deletion(-)
Thanks for the fix. I think `use prefix` is more encouraged than [[ -n ${EPREFIX} ]].
Sigh, I should have tried to include a library with my simple test: $ cat test.c #include <stdlib.h> int main() { return 0; } core@root-build ~ $ clang test.c test.c:1:10: fatal error: 'stdlib.h' file not found #include <stdlib.h> ^~~~~~~~~~ 1 error generated. I see Benda fixed sci-physics/root by adding -DDEFAULT_SYSROOT=${EPREFIX}, but for clang alone that is not enough, we also need at least -DC_INCLUDE_DIRS=${EPREFIX}/usr/include to make it find the headers from prefix.
(In reply to Benda Xu from comment #9) > Thanks guys. > > We did a dirty hack to gcc for it to look for all the libc objects inside > EPREFIX. > > > https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/features/prefix/ > standalone/profile.bashrc#n9 > > sys-devel/clang would require a similar treatment. Hi Benda, I think I finally understand the problem. When I configure clang with -DDEFAULT_SYSROOT=${EPREFIX}, the linker gets double prefix, so we need to remove it, as was done for GCC (from link above): > ebegin "remove --sysroot call on ld for native toolchain" > sed -i 's/--sysroot=%R//' gcc/gcc.c > eend $? Can you please explain what exactly have been the changes you needed for GCC? Fabian patched Clang for macOS, but unfortunately it seems that we will need two different configurations on prefix, one for Linux (i.e. prefix-standalone) and one for the others, as at least on macOS -DDEFAULT_SYSROOT=${EPREFIX} does not work. The difference being how we use RPATH and where libc comes from.
Finally fixed this: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9f5cbe65e5f2689faf356e647d889aa3dab0cdd4 commit 9f5cbe65e5f2689faf356e647d889aa3dab0cdd4 Author: Guilherme Amadio <amadio@gentoo.org> Date: Thu Jul 5 19:27:25 2018 +0200 profiles: fix sys-devel/clang on standalone prefix On standalone prefix, sys-devel/clang needs to be configured with -DDEFAULT_SYSROOT=${EPREFIX} and also needs the same treatment as sys-devel/gcc to remove --sysroot=${EPREFIX} from ld calls.
