| Summary: | clang++ looking at the wrong place for libstdc++ headers | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Cesar Eduardo Barros <cesarb> |
| Component: | llvm | Assignee: | Michel Alexandre Salim <michel> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | atherchris, bogado, bos, dmalcolm, dtardon, michel, schlaffi |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-30 06:42:08 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
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 *** |
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.