Description of problem: clang++ is looking at /usr/include/c++/4.6.0 for the headers which are at /usr/include/c++/4.6.1 Version-Release number of selected component (if applicable): llvm-2.8-12.fc15.x86_64 libstdc++-devel-4.6.1-9.fc15.x86_64 How reproducible: Always. Steps to Reproduce: 1. Write a simple C++ hello world including for instance <iostream> 2. Try to compile it with clang++ (for instance "clang++ -v hello.cc -o hello") Actual results: clang version 2.8 (branches/release_28) Target: x86_64-redhat-linux-gnu Thread model: posix "/usr/bin/clang" -cc1 -triple x86_64-redhat-linux-gnu -S -disable-free -disable-llvm-verifier -main-file-name hello.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.51.0.6 -v -resource-dir /usr/lib/clang/2.8 -ferror-limit 19 -fmessage-length 80 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-u9WH5O.s -x c++ hello.cc clang -cc1 version 2.8 based upon llvm 2.8 hosted on x86_64-redhat-linux-gnu ignoring nonexistent directory "/usr/include/c++/4.6.0" ignoring nonexistent directory "/usr/include/c++/4.6.0/x86_64-redhat-linux/" ignoring nonexistent directory "/usr/include/c++/4.6.0/backward" ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.6.0/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/clang/2.8/include /usr/include End of search list. hello.cc:1:10: fatal error: 'iostream' file not found #include <iostream> ^ 1 error generated. Expected results: It should look at the correct place for the libstdc++ headers. Additional info: This probably started happening after FEDORA-2011-11526. Fixing this bug is probably a simple matter of recompiling the package. If this is the case, it might be a good idea to always recompile it when a new gcc package is compiled.
I just thought of another way to avoid this problem in the future: clang could add a versioned dependency to libstdc++-devel, which would prevent updating gcc until llvm was recompiled to match.
just a ping, that this problem still exists. OK nobody uses clang++ except for playing around, obviously :) clang-2.9-4.fc16.x86_64 & gcc-4.6.2-1.fc16.x86_64
The problem persists. :-(
This issue is caused the hard-coded lookups clang does for gcc stuff, I think. Looks like a gcc upgrade that clang-2.9 doesn't know about. All you have to do is update the add-gcc-vers patch to include 4.6.2 and it works.
*** This bug has been marked as a duplicate of bug 750187 ***