| Summary: | sys-devel/clang-9999 detects wrong libstdc++ include / library path | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Matthias Dahl <ua_gentoo_bugzilla> |
| Component: | [OLD] Core system | Assignee: | Gentoo Clang Team (OBSOLETE) <clang+obsolete> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | leonid, p, pageexec |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
http://llvm.org/bugs/show_bug.cgi?id=12479 http://llvm.org/bugs/show_bug.cgi?id=12955 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 408963 | ||
| Attachments: |
Patch proposal that adds runtime detection of correct GCC version
Patch proposal that adds runtime detection of correct GCC version |
||
|
Description
Matthias Dahl
2012-02-28 15:04:20 UTC
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 |
