I am currently having a bit of trouble with Clang. (bug #406163) And one part of it is related to Gentoo's non-standard handling of the gcc installation... more precisely where it places the header "cxxabi.h" which belongs to libstdc++. Straight from the friendly llvm guys: " chandlerc: BinaryKhaos: cxxabi.h must *not* be in the same directory as GCC's builtin headers (like x86intrin.h). It is part of libstdc++, not part of GCC's internals. " So currently cxxabi.h is placed in /usr/lib64/gcc/x86_64-pc-linux-gnu/<gcc-version>/include while it should actually be in /usr/lib64/gcc/x86_64-pc-linux-gnu/<gcc-version>/include/g++-v4 Thus Clang++ is correctly not checking one level above and naturally doesn't find it. Is there any chance this can be fixed on our side? One example where this is causing trouble: chromium fails to compile because of this.
clang++ does a lot of ugly crap, so i'm no surprised they fall flat based on all of their fragile assumptions as to the cxxabi.h move in Gentoo, azarah did that years ago, and the commit doesn't explain why beyond "This build enables us to have multiple versions of gcc installed": http://sources.gentoo.org/sys-devel/gcc/gcc-3.0.4-r2.ebuild?view=log http://sources.gentoo.org/sys-devel/gcc/ChangeLog?r1=1.2&r2=1.3 maybe the include dir layout at the time looked very different from what we have today: the include dir is SLOT-ed based on CTARGET/PV. so i don't see the point in moving it anymore. i like deleting code from toolchain.eclass: http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.517&r2=1.518
Thanks for your swift reaction, it's very much appreciated. (In reply to comment #1) > clang++ does a lot of ugly crap, so i'm no surprised they fall flat based on > all of their fragile assumptions In all honesty, so does gcc. And in this particular case, the header was inarguably in a non-standard place, so expecting them to find it, is like changing everything in a blind man's room and blaming him for stumpling upon everything. ;) And to be quite frank, all the conversations I had so far w/ the llvm devs were open, friendly, welcoming and helpful... quite the contrast to what my experience is w/ the gcc devs.
(In reply to comment #2) i don't think your analogy is accurate. it's more like a blind man walking into your room and getting pissed when he stumbles over your stuff strewn about.
(In reply to comment #3) > i don't think your analogy is accurate. it's more like a blind man walking > into your room and getting pissed when he stumbles over your stuff strewn > about. Ok. What about this (imho) very fitting one... :-) Your appartment is absolutely blind-friendly, with everything properly marked in braille. Now you have a blind man as a guest who wants to use the rest room which he finds on himself because you marked everything properly. Yet there is no loo because you decided to put into the kitchen where you think it belongs and the blind man is pissed about it. ;) I suggest, if we wanna continue this, we should do so by mail. On the bright side, I could really use the practice as I usually suck at analogies. ;-))
(In reply to comment #4) i think you're assuming more about gcc than you should. their headers are their headers. the fact that clang++ works with them is because they added gcc-compatibility to them. in the end, they're attempting to emulate gcc without being gcc and grub around gcc's layout to do so.
