I have several gcc versions installed (4.5.3-r2, 4.6.2, 4.6.3_pre9999, 4.7.0_alpha20120114) and clang always detects the highest gcc version available for its include and library path. This is bound to cause trouble when the actual active version is for example 4.6.x and clang uses the libstdc++ related stuff from 4.7.0_alpha during compile and link time. (like in my case) Compiling a simple helloworld.cpp: clang version 3.1 (trunk) Target: x86_64-pc-linux-gnu Thread model: posix "/usr/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name helloworld.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.1 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/include/g++-v4 -internal-isystem /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/include/g++-v4/x86_64-pc-linux-gnu -internal-isystem /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/include/g++-v4/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /root -ferror-limit 19 -fmessage-length 188 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/helloworld-fyDgWY.o -x c++ helloworld.cpp clang -cc1 version 3.1 based upon LLVM 3.1svn default target x86_64-pc-linux-gnu ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/include/g++-v4 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/include/g++-v4/x86_64-pc-linux-gnu /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/include/g++-v4/backward /usr/local/include /usr/bin/../lib/clang/3.1/include /usr/include End of search list. "/usr/bin/x86_64-pc-linux-gnu-ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o helloworld /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/../../../../lib64/crt1.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/../../../../lib64/crti.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/crtbegin.o -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/../../.. -L/lib -L/usr/lib /tmp/helloworld-fyDgWY.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/crtend.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120114/../../../../lib64/crtn.o This was tested with today's trunk and ebuild on a ~AMD64 system. Reproducible: Always
I might be wrong but shouldn't /usr/lib64/gcc/x86_64-pc-linux-gnu/<gcc-version>/include/ also be in the path as well? Otherwise packages might fail because clang can't find cxxabi.h which is located there as well. One example for this is chromium which fails to due to not finding cxxabi.h.
Ok... Clang++ not finding "cxxabi.h" is actually a problem on our side, so I have opened bug 406209 about it. Regarding the priority of the different include paths itself. That is intended behavior. Clang++ always uses the highest version installed which imho can cause trouble (see above). There is a new configure option (also exposed as runtime option) according to one of the llvm guys "-gcc-toolchain" or similar which we could use to fix this to our needs. (haven't checked it yet, since I am in hurry and short on time, sorry)
*** Bug 405233 has been marked as a duplicate of this bug. ***
Thanks for your work on this :) I thought the gcc-toolchain option was something like our PREFIX variable, I'll update my 9999 checkout and look at it again
Sure thing. I'm glad to help. I'm sorry I cannot be of more use currently as I am writing my degree dissertation and have only a few weeks left. But if there is anything else, just let me know. I really would like to see the clang support in Gentoo flourish.
I finally had some time to look at this, for now I think the cleanest way would be to have a "-gcc-version" option in llvm/clang close to the existing "-gcc-toolchain" When looping over /usr/lib/gcc/x86_64-pc-linux-gnu/ (or wherever the detector goes), instead of looping over folders and stopping at the highest version, a first test would be run on /usr/lib/gcc/x86_64-pc-linux-gnu/"gcc-version" if it is set I'll open a bugreport upstream to see what they think of this (or if they have a better solution)
The relevant upstream bug is in the "See Also" part: http://llvm.org/bugs/show_bug.cgi?id=12479 (commenting here to make it more visible :) )
It might be possible to resolve this by modifying gcc-config to install a symlink to libstdc++ in /usr/lib.
Created attachment 312865 [details, diff] Patch proposal that adds runtime detection of correct GCC version (In reply to comment #8) > It might be possible to resolve this by modifying gcc-config to install a > symlink to libstdc++ in /usr/lib. On second thought, that is pointless because gcc-config modifies /etc/env.d, which tells the dynamic linker where to find libstdc++. I have written a patch that adds runtime detection of the correct GCC version. The patch also adds hooks to Clang's distribution detection so that it can explicitly detect Gentoo. That is pointless right now, but I wrote that with the intention of sending it upstream. voyageur, let me know if it is okay to commit this to portage.
(In reply to comment #9) > voyageur, let me know if it is okay to commit this to portage. Disregard that comment. I missed a regression. This needs a bit more work before it can be committed to the tree.
Created attachment 312871 [details, diff] Patch proposal that adds runtime detection of correct GCC version I have attached a proper patch to address this. This one applies against clang 3.0 and works well in my testing. With a GCC 4.5-built LLVM and Clang, I can do `gcc-config gcc-config x86_64-pc-linux-gnu-4.5.3` and `gcc-config x86_64-pc-linux-gnu-4.6.3` to switch back and forth and `clang -v hello.c` indicates that it is linking to the correct libstdc++ each time. voyageur, let me know if it is okay to commit this.
I have updated my patch for Clang 3.1 and committed it to CVS as part of sys-devel/clang-3.1-r1. My position on 9999 ebuilds is that patches against them should be sent upstream rather than put into the tree, although the decision belongs to the sys-devel/clang maintainers. Matthias, do you have any particular need for sys-devel/clang-9999? Try sys-devel/clang-3.1-r1 and see if it resolves your problems. If it does, you could always create the /etc/portage/patches/sys-devel/clang-9999 directory and put copies of my 3.1 patches into it.
just FYI, if you want to get patches accepted into llvm/clang then you should post them to llvm-commits/cfe-commits for review (instead of their bugzilla).
Cleaning old bugs, this has probably been fixed for some time but I just retested it (switching between my system 4.9.3 and 5.2.0), it got the correct libstdc++ and headers
