Created attachment 376736 [details] build.log Build log attached. No ide why it tries to include something from gcc, previous versions of eix compiled without any problems.
Please, try to reproduce it.
IIRC, clang provides no c++ library, so it just uses that from gcc. The code which fails in eix is completely harmless: #include <string> So I suppose that something is messed up with your compilers. Maybe the two versions of gcc and clang which you have installed do not work with each other. I guess there is nothing reasonable which can be done in eix about it.
Yes, you are right, libcxx is a separated project, so clang indeed uses gcc's one. What seemed strange to me that previous version of eix compiled without any problems. So let me see, if it's indeed some mess on my machine I'll just close this bug, otherwise i'll post additional info.
Ok, it's not the mess on my computer, it's switching in eix to c++-1y: http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header It seems to be a bug in <gcc-4.9
Thanks for the analysis. The test for c++1y now adds #include <unistd.h> #include <string> I hope that this triggers the issue. The new test is in eix git master on BerliOS and GitHub. If you find the time, please test (a live ebuild is in the mv overlay).
app-portage/eix-99999999 compiles with clang. but there are runtime problems now: when called it hangs forever. i have no time to look at the reason currently, will address it later. It would be helpfull if you compiled eix with clang and tried to run it and see if it works.
(In reply to Jauhien Piatlicki from comment #6) > app-portage/eix-99999999 compiles with clang. Thanks for testing > It would be helpfull if you compiled eix with clang I always develop/test with clang and never had problems with it (but I did not switch various gcc and glibc versions when doing so) > but there are runtime problems now [...] hangs forever Thanks for the reminder: These arose here with upgrade to clang-4.3.1-r100, and so I had conjectured a bug of that particular version. I will look at it when I have time.
(In reply to Martin Väth from comment #7) > Thanks for the reminder: These arose here with upgrade to clang-4.3.1-r100 I remember now that I had already checked and decided that I do not know what to do about it: It is simply the first call of fread() which does not return, and the issue is avoided if -D_FORTIFY_SOURCE=2 is not passed on the command line. Really, it seems to be a problem of clang with handling D_FORTIFY_SOURCE=2 incorrectly (perhaps in the interplay with gentoo's patches for gcc/glibc for D_FORTIFY_SOURCE=2?). I cannot write a compatible ./configure test for this issue. You can avoid it "manually" by USE="-security -strong-security"
eix-0.30.10.ebuild eix-0.30.11.ebuild eix-0.30.4.ebuild eix-0.31.4.ebuild eix-0.31.6.ebuild eix-0.31.7.ebuild eix-0.31.7-r1.ebuild all work for me with sys-devel/clang-3.4.2-r100, sys-devel/clang-3.5.0-r100, and sys-devel/clang-3.7.1-r100 (current stable clang versions). I also tried with eix-0.30.2 (had to copy 0.30.4's ebuild, and add eautoreconf, using a tarball I manually prepared from a git checkout). That also worked in all three clang versions as well.
