Description of problem: The clang 3.0-14 package can not find the necessary headers/libraries correctly. The clang compiler must find both the gcc C++ standard library headers/libs and the gcc C standard library headers/libs. While it find the former it is not setup correctly to find the latter. This is evident from the output from: clang -v -fsyntax-only -x c++ /dev/null "clang version 3.0 (tags/RELEASE_30/final) Target: x86_64-redhat-linux-gnu Thread model: posix "/usr/bin/clang" -cc1 -triple x86_64-redhat-linux-gnu -fsyntax-only -disable-free -disable-llvm-verifier -main-file-name null -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.22.52.0.1 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.0 -fmodule-cache-path /var/tmp/clang-module-cache -I /opt/intel/composerxe-2011.5.220/mkl/include -I /opt/intel/composerxe-2011.5.220/tbb/include -I /opt/intel/composerxe-2011.5.220/mkl/include -I /opt/intel/composerxe-2011.5.220/tbb/include -internal-isystem /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2 -internal-isystem /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/x86_64-redhat-linux -internal-isystem /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.0/include -internal-externc-isystem /usr/include -fdeprecated-macro -ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -x c++ /dev/null clang -cc1 version 3.0 based upon llvm 3.0 hosted on x86_64-redhat-linux-gnu ignoring duplicate directory "/opt/intel/composerxe-2011.5.220/mkl/include" ignoring duplicate directory "/opt/intel/composerxe-2011.5.220/tbb/include" #include "..." search starts here: #include <...> search starts here: /opt/intel/composerxe-2011.5.220/mkl/include /opt/intel/composerxe-2011.5.220/tbb/include /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2 /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/x86_64-redhat-linux /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/backward /usr/local/include /usr/bin/../lib/clang/3.0/include /usr/include End of search list." As can be seen the gnu C standard library headers, which are at /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include, are not found. This bug has already been confirmed by the clang development team, but needs to be fixed by whomever packaged clang 3.0 for Fedora 17. As clang 3.0 is now packaged for Feedora 17, it is currently unusable.
Why are you filing clang bugs against gcc?
I think I'm also being bitten by this bug, where clang++ is not able to compile stuff that requires gcc C macros on Fedora 18. Shall I clone this bug?
Any more details? The above output is not terribly clear to me. What exactly is expected?
Hi Jens, Please compare the outputs of clang on FC 16 (where everything was working fine) and FC 18 (where currently we have a problem): FC 16: [zaytsev@fc-16-i386-1 ~]$ clang -v -fsyntax-only -x c++ /dev/null clang version 2.9 (tags/RELEASE_29/final) Target: i386-redhat-linux-gnu Thread model: posix "/usr/bin/clang" -cc1 -triple i386-redhat-linux-gnu -fsyntax-only -disable-free -disable-llvm-verifier -main-file-name null -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.21.53.0.1 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 211 -fcxx-exceptions -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -x c++ /dev/null clang -cc1 version 2.9 based upon llvm 2.9 hosted on i386-redhat-linux-gnu #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.6.3 /usr/include/c++/4.6.3/i686-redhat-linux /usr/include/c++/4.6.3/backward /usr/local/include /usr/bin/../lib/clang/2.9/include /usr/include /usr/lib/gcc/i686-redhat-linux/4.6.3/include End of search list. FC 18: [zaytsev@fc-18-i386-1 ~]$ clang -v -fsyntax-only -x c++ /dev/null clang version 3.1 (branches/release_31) Target: i386-redhat-linux-gnu Thread model: posix "/usr/bin/clang" -cc1 -triple i386-redhat-linux-gnu -fsyntax-only -disable-free -disable-llvm-verifier -main-file-name null -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.23.51.0.1 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.1 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2 -internal-isystem /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/i686-redhat-linux -internal-isystem /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /home/zaytsev -ferror-limit 19 -fmessage-length 211 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -x c++ /dev/null clang -cc1 version 3.1 based upon LLVM 3.1 default target i386-redhat-linux-gnu ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2 /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/i686-redhat-linux /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/backward /usr/local/include /usr/bin/../lib/clang/3.1/include /usr/include End of search list. You will see that the analog of on FC 16 /usr/lib/gcc/i686-redhat-linux/4.6.3/include which should be on FC 18 /usr/lib/gcc/i686-redhat-linux/4.7.2/include is missing from the library search path! Here I attach a tentative patch to the spec from rawhide which re-introduces the --with-c-include-dirs option that was lost sometime between 2.9 and 3.1 (although a bit differently, because %{_include} was not really necessary). I'm willing to test the resulting FC18 packages for you in order to confirm that the problem is indeed fixed. Hope that helps, --Yury.
Created attachment 688846 [details] Re-introduce lost --with-c-include-dirs option in the SPEC
(In reply to comment #5) > Created attachment 688846 [details] > Re-introduce lost --with-c-include-dirs option in the SPEC This is not working on FC17. Could we not have a fix for FC17 please in the form of an update ?
Hi Edward, What do you mean by that? You recompiled the package with my patch and it's still not working? --Yury.
(In reply to comment #7) > Hi Edward, > > What do you mean by that? You recompiled the package with my patch and it's > still not working? > > --Yury. I meant that I would like to see an updated binary version on Fedora 17 as an RPM package which fixes the problem. Is that really asking for too much ? I have no idea how I am supposed to use your patch to build a correct version for Fedora 17. I imagine I must get the source, apply your patch, and then build the source. Are there instructions for doing this anywhere ?
> I meant that I would like to see an updated binary version on Fedora 17 as an > RPM package which fixes the problem. Is that really asking for too much ? Not really, but you are barking at the wrong person :-) I'm just trying to help fixing this problem by offering a possibly working patch. I'm not a Fedora packager and I can't issue distro updates. > I imagine I must get the source, apply your patch, and then build the source. > Are there instructions for doing this anywhere ? We have some instructions, that are specific to RHEL, but should work on Fedora too here: http://repoforge.org/package/quickstart.html Basically you should rpm -ivh the srpm of llvm, patch the SPEC, produce a new srpm with rpmbuild and then rebuild it with mock. I could have provided you with a test package, but I don't have a working build host at the moment, and, as I said, I don't have access to Fedora's koji server either.
(In reply to comment #4) > Here I attach a tentative patch to the spec from rawhide which re-introduces > the --with-c-include-dirs option that was lost sometime between 2.9 and 3.1 > (although a bit differently, because %{_include} was not really necessary). Ok I managed to track down the commit that removed --with-c-include-dirs and also similar options for c++: http://pkgs.fedoraproject.org/cgit/llvm.git/commit/?id=9ff19058fe57f17611b53d028b5251080acc7ec7 Michel, do you remember why by chance?
Here is a test build for F18: http://koji.fedoraproject.org/koji/taskinfo?taskID=4926585
Sadly, I'm unable to test these packages: Error: Package: clang-3.1-16.fc18.i686 (fc-local-binary) Requires: libstdc++-devel = 4.8.0 Installed: libstdc++-devel-4.7.2-8.fc18.i686 (@anaconda) libstdc++-devel = 4.7.2-8.fc18 Strangely, it seems that a newer version has got into koji build root as opposed to what is publicly available for FC18...
Hi Jens, Here is the problem: # clang header paths are hard-coded at compile time # and need adjustment whenever there's a new GCC version -%global gcc_version 4.8.0 +%global gcc_version 4.7.2 You need to do this in the FC18 branch (rawhide has 4.8.0 already, so this is correct for FC19), so that the package can be installed on FC18. HTH, --Yury.
Right thanks, Yury - I had just noticed that myself before trying.
I wonder though if llvm should not BR with %gcc_version too though.
Anyway I tested the build in rawhide and it seems to do the right kind of thing. Before I commit and build the fix, can someone post a link to or some small test-case to check that this fix really works?
Test scratch build for f18 with backported fixes from rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=4929918
Something very strange happening here (everything is completely broken now): [zaytsev@fc-18-i386-1 ~]$ clang -v -fsyntax-only -x c /dev/null clang version 3.1 (branches/release_31) Target: i386-redhat-linux-gnu Thread model: posix "/usr/bin/clang" -cc1 -triple i386-redhat-linux-gnu -fsyntax-only -disable-free -disable-llvm-verifier -main-file-name null -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.23.51.0.1 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.1 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.1/include -internal-externc-isystem /usr/lib/gcc/%{arch}*/4.7.2/include -fdebug-compilation-dir /home/zaytsev -ferror-limit 19 -fmessage-length 211 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -x c /dev/null clang -cc1 version 3.1 based upon LLVM 3.1 default target i386-redhat-linux-gnu ignoring nonexistent directory "/usr/lib/gcc/%{arch}*/4.7.2/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/bin/../lib/clang/3.1/include End of search list. I need to have a look at the SPEC, looks like %{arch} somehow didn't get expanded?!
Hi Jens, I think that if you want to do it this way, it should be something like: - --with-c-include-dirs=$(echo %{_prefix}/lib/gcc/%{arch}*/%{gcc_version}/include) + --with-c-include-dirs=$(echo %{_prefix}/lib/gcc/%{_arch}*/%{gcc_version}/include) (I didn't test it though) HTH, --Yury.
Thanks for testing. Okay sorry hopefully should be right in http://koji.fedoraproject.org/koji/taskinfo?taskID=4931730 . ps Doing it this way should prevent problems with multilib installs hopefully.
Looks ok to me on x86_64 at least.
Fat chance on i386, Jens: ignoring nonexistent directory "/usr/lib/gcc/i386*/4.7.2/include" ...
I see thanks - guess I better stop being lazy use %_target_cpu then. I seem to remember that somehow %_arch might behave differently in the buildsys. Hopefully this time: http://koji.fedoraproject.org/koji/taskinfo?taskID=4935510
Hi Jens, Your patch worked, but now /usr/include is missing from the search path. I'm sorry, I think this is my fault. I was wrong when I said that it will be added automatically, it looks like it's only added if --with-c-include-dirs is not given. So apparently it should be - --with-c-include-dirs=$(echo %{_prefix}/lib/gcc/%{_target_cpu}*/%{gcc_version}/include) + --with-c-include-dirs=%{_includedir}:$(echo %{_prefix}/lib/gcc/%{_target_cpu}*/%{gcc_version}/include) It seems that Michel put %{_includedir} there for a reason... #include <...> search starts here: /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2 /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/i686-redhat-linux /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/backward /usr/local/include /usr/bin/../lib/clang/3.1/include /usr/lib/gcc/i686-redhat-linux/4.7.2/include End of search list. I'm really sorry, I didn't mean to be a PITA when I joined this report :-/ --Yury.
No worries - appreciate your help, Yury! :) Ok, committed to pkg git master: http://pkgs.fedoraproject.org/cgit/llvm.git/commit/?id=a185901e955b539aaf2f08a48a563fad06dc79cc and building llvm-3.1-16.fc19 for rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=4938089 and here is a another scratch test backport build for f18: http://koji.fedoraproject.org/koji/taskinfo?taskID=4938095
Would still appreciate a small non-trivial testcase just to check that this now works correctly.
Forgot to acknowledge Yury's help. http://pkgs.fedoraproject.org/cgit/llvm.git/commit/?id=b8204c16e049b4844a05f91206f42e5c40db07c9
Hi Jens, Works for me, thanks for your efforts! Re. test case, I'm compiling a huge pile of C++ code that links to C code on my Fedora builders, so if it can't find the headers, the compilation fails, but it's a difficult task to extract a minimal test case. Edward Diener, maybe you have one? Also, the pointer to the dicussion with Clang devs would be helpful... Best, --Yury.
(In reply to comment #28) > Hi Jens, > > Works for me, thanks for your efforts! Re. test case, I'm compiling a huge > pile of C++ code that links to C code on my Fedora builders, so if it can't > find the headers, the compilation fails, but it's a difficult task to > extract a minimal test case. > > Edward Diener, maybe you have one? Also, the pointer to the dicussion with > Clang devs would be helpful... > > Best, > --Yury. I was testing out building the latest version of clang from source with the binary version of clang distributed as a package in FC17. Attempting to build failed and when I contacted llvm/clang development one of the developers told me to try a switch that shows the header file directories which the binary version of clang was finding. When I did that I noticed that it was not finding the C headers for the installed version of gcc although it was finding the C++ headers. Subsequently, with my information, the 'configure' script for llvm was updated so that if the compiler did not include the correct headers the 'configure' script would fail before a user even tried to use the compiler to do a build. This is an improvement. I was asked to report the problem to Fedora in a bug report and that led to this bug report. I would be glad to test the fix if I could get a binary for FC17 on which to test it. OTOH if an updated binary has been created for FC18 I can try to upgrade to FC18, and then test it there. If I can get specific instructions on what to do to upgrade my binary from source for clang on FC17 I am willing to try that. My test case in all conditions is simply running the 'configure' script for the latest clang with the appropriate early version of the compiler chosen to build the latest version, and see if the 'configure' script succeeds or not. Alternatively I can simply pass the command line parameters to the binary version of clang and not whether it is finding the C header file directory. I know it sounds strange to be concerned about an earlier binary distributed version of clang on FC17 when I am also building the latest version from source, but I need to be able to test both versions with some work I am doing in C++ template metaprogramming for Boost.
> OTOH if an updated binary has been created for FC18 I can try to upgrade to FC18, and then test it there. Yes, see above. > If I can get specific instructions on what to do to upgrade my binary from source for clang on FC17 I am willing to try that. It's complicated. As I said earlier, you will basically have to rebuild the package yourself. > My test case in all conditions is simply running the 'configure' script for the > latest clang with the appropriate early version of the compiler chosen to build > the latest version So what I did was to take llvm-3.2.src.tar.gz & clang-3.2.src.tar.gz, extract them, put clang into llvm/tools, then create a build directory and run ../llvm/configure. It succeeded with both stock FC18 package and the updated one with fixed include paths. N.B. I did export the CC/CXX variables prior to running configure. export CC=clang export CXX=clang++ Which is the "latest" version that you are building?
(In reply to comment #28) > Works for me, thanks for your efforts! Re. test case, I'm compiling a huge > pile of C++ code that links to C code on my Fedora builders, so if it can't > find the headers, the compilation fails, but it's a difficult task to > extract a minimal test case. Ok no worries - just wondered if you guys had something less trivial than /dev/null to test or maybe some package build failure to test against. Anyway the trivial output looks ok and it seems to be working for you now, so I think it is fine. (In reply to comment #29) > Subsequently, with my information, the 'configure' script for llvm was > updated so that if the compiler did not include the correct headers the > 'configure' script would fail before a user even tried to use the compiler > to do a build. This is an improvement. I was asked to report the problem to > Fedora in a bug report and that led to this bug report. I see, thank you! > I would be glad to test the fix if I could get a binary for FC17 on which to > test it. You can try: http://koji.fedoraproject.org/koji/taskinfo?taskID=4941456 I don't know if we will still backport 3.1 to F17: I see Michel did a build in Nov but never pushed it - maybe he didn't have time to rebuild the dependent packages?
(In reply to comment #30) > > OTOH if an updated binary has been created for FC18 I can try to upgrade to FC18, and then test it there. > > Yes, see above. > > > If I can get specific instructions on what to do to upgrade my binary from source for clang on FC17 I am willing to try that. > > It's complicated. As I said earlier, you will basically have to rebuild the > package yourself. > > > My test case in all conditions is simply running the 'configure' script for the > > latest clang with the appropriate early version of the compiler chosen to build > > the latest version > > So what I did was to take llvm-3.2.src.tar.gz & clang-3.2.src.tar.gz, > extract them, put clang into llvm/tools, then create a build directory and > run ../llvm/configure. > > It succeeded with both stock FC18 package and the updated one with fixed > include paths. N.B. I did export the CC/CXX variables prior to running > configure. > > export CC=clang > export CXX=clang++ > > Which is the "latest" version that you are building? The latest version I am building is whatever I get when updating the llvm/clang tree via svn. The 'configure' script does fail if the version of the compiler you are using to build clang does not have the correct 'include' directory paths. See http://clang.llvm.org/get_started.html for getting the latest version via svn and building from source.
Hi Edward, Now I am completely confused... I checked out llvm and clang from svn, and with the stock FC18 package configure works. If I install the package that adds gcc C library to the search path: /usr/lib/gcc/i686-redhat-linux/4.7.2/include then configure actually fails. The reason why it fails, is because it can't compile the test that includes <unwind.h>, apparently due to some incompatibility between clang and gcc. > [zaytsev@fc-18-i386-1 src]$ clang++ test.cpp > In file included from test.cpp:15: > In file included from /usr/bin/../lib/clang/3.1/include/unwind.h:44: /usr/lib/gcc/i686-redhat-linux/4.7.2/include/unwind.h:43:46: error: unknown machine mode '__unwind_word__' > typedef unsigned _Unwind_Word __attribute__((__mode__(__unwind_word__))); > ^ > /usr/lib/gcc/i686-redhat-linux/4.7.2/include/unwind.h:44:45: error: unknown machine mode '__unwind_word__' > typedef signed _Unwind_Sword __attribute__((__mode__(__unwind_word__))); > ^ > 2 errors generated. Now, I also have a FC17 machine with stock unmodified clang from Fedora installed there. And the configuration of svn version of clang actually *does* work. So if it doesn't work for you, then you must have messed up your system. Also, the MKL includes in your original post look suspicious... I checked up the mailing lists, and I haven't found the message where you have been explicitly given the recommendation to include /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include into the search path. Can you please link to the specific post? Now my problems seem to be different in a way that my codes do not compile because clang doesn't seem to recognize that it should use C versions of headers instead of C++ in extern "C" context, so fixing this by mixing libraries even if it solves the problem for me right now is wrong, because apparently it breaks other things. I will try to talk to some folks from llvm on IRC to figure what would they advise with respect to the --with-c-include-dirs=%{_includedir}:$(echo %{_prefix}/lib/gcc/%{_target_cpu}*/%{gcc_version}/include) option. Z.
(In reply to comment #33) > Hi Edward, > > Now I am completely confused... I checked out llvm and clang from svn, and > with the stock FC18 package configure works. If I install the package that > adds gcc C library to the search path: > > /usr/lib/gcc/i686-redhat-linux/4.7.2/include > > then configure actually fails. The reason why it fails, is because it can't > compile the test that includes <unwind.h>, apparently due to some > incompatibility between clang and gcc. > > > [zaytsev@fc-18-i386-1 src]$ clang++ test.cpp > > In file included from test.cpp:15: > > In file included from /usr/bin/../lib/clang/3.1/include/unwind.h:44: > /usr/lib/gcc/i686-redhat-linux/4.7.2/include/unwind.h:43:46: error: unknown > machine mode '__unwind_word__' > > typedef unsigned _Unwind_Word __attribute__((__mode__(__unwind_word__))); > > ^ > > /usr/lib/gcc/i686-redhat-linux/4.7.2/include/unwind.h:44:45: error: unknown machine mode '__unwind_word__' > > typedef signed _Unwind_Sword __attribute__((__mode__(__unwind_word__))); > > ^ > > 2 errors generated. > > Now, I also have a FC17 machine with stock unmodified clang from Fedora > installed there. And the configuration of svn version of clang actually > *does* work. So if it doesn't work for you, then you must have messed up > your system. Also, the MKL includes in your original post look suspicious... > > I checked up the mailing lists, and I haven't found the message where you > have been explicitly given the recommendation to include > /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include into the search path. Can you > please link to the specific post? > > Now my problems seem to be different in a way that my codes do not compile > because clang doesn't seem to recognize that it should use C versions of > headers instead of C++ in extern "C" context, so fixing this by mixing > libraries even if it solves the problem for me right now is wrong, because > apparently it breaks other things. > > I will try to talk to some folks from llvm on IRC to figure what would they > advise with respect to the > > --with-c-include-dirs=%{_includedir}:$(echo > %{_prefix}/lib/gcc/%{_target_cpu}*/%{gcc_version}/include) > > option. > > Z. With the clang binary package for FC17 installed and llvm/clang installed in ~/vcs/llvm if I try, from a build directory: CC=clang CXX=clang++ ~/vcs/llvm/congigure I get: checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether clang accepts -g... yes checking for clang option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether clang++ accepts -g... yes checking how to run the C preprocessor... clang -E checking whether clang works... no configure: error: Selected compiler could not find or parse C++ standard library headers. Rerun with CC=c-compiler CXX=c++-compiler ./configure ... If I try: clang -v -fsyntax-only -x c++ /dev/null I get at the end of the output: #include <...> search starts here: /opt/intel/composerxe-2011.5.220/mkl/include /opt/intel/composerxe-2011.5.220/tbb/include /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2 /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/x86_64-redhat-linux /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/backward /usr/local/include /usr/bin/../lib/clang/3.0/include /usr/include which clearly shows that clang 3.0 for FC17 does not have the C header file directory in its path.
> With the clang binary package for FC17 installed and llvm/clang installed in ~/vcs/llvm if I try, from a build directory: Too bad, because it works for me on a freshly installed FC17 i386 machine. Can you show the output of "which clang++" and then readlink on the resulting path? I don't understand where these paths > /opt/intel/composerxe-2011.5.220/mkl/include > /opt/intel/composerxe-2011.5.220/tbb/include come from. They should not be present in the stock Fedora clang++. Do you have any extra compiler packages installed, or several different versions of clang deployed? Also, I have extracted this test from configure, and will attach it to this report in a moment. Can you compile it with clang++ to see which error exactly are you getting? The configure script only tells you that it failed, it doesn't tell you how and why, which would be very helpful in diagnosing this issue.
Created attachment 695583 [details] Test performed by clang configure script
(In reply to comment #34) > which clearly shows that clang 3.0 for FC17 does not have the C header file > directory in its path. So can you please try with: http://koji.fedoraproject.org/koji/taskinfo?taskID=4941456 that I built for you? (You may need to remove or ignore some conflicting mesa package dependencies.)
Hmm, I can't rebuild llvm locally with llvm/clang installed. Maybe llvm.spec should be configured not to build with itself?
(In reply to comment #38) > Hmm, I can't rebuild llvm locally with llvm/clang installed. Actually with clang installed (with llvm installed is ok).
> Actually with clang installed (with llvm installed is ok). This is the problem that I was referring to in #33. Try to comment > --with-c-include-dirs=%{_includedir}:$(echo %{_prefix}/lib/gcc/%{_target_cpu}*/%{gcc_version}/include) and then rebuild it with itself. Maybe that's why Michel disabled it in the first place. I don't quite understand whether this is a compatibility problem with GCC or generic configuration issue. I haven't yet gotten around asking clang devs about it as promised.
(In reply to comment #40) > > Actually with clang installed (with llvm installed is ok). > > This is the problem that I was referring to in #33. Right > Try to comment > > --with-c-include-dirs=%{_includedir}:$(echo %{_prefix}/lib/gcc/%{_target_cpu}*/%{gcc_version}/include) That still fails for me later with "too many compilation errors" (for size_t etc). Anyway there is a simple workaround for llvm.spec: %global optflags %(echo %{optflags} | sed 's/-O2 /-O2 -fno-tree-pre /') +export CC=gcc +export CXX=c++ # Disabling assertions now, rec. by pure and needed for OpenGTL %configure \ llvm failing to build with clang might not be Fedora specific? > I don't quite understand whether this is a compatibility problem with GCC or > generic configuration issue. I haven't yet gotten around asking clang devs > about it as promised. Ok, if there is a better solution we can certainly use that. For now I am happy enough just to go with setting CC and CXX. Certainly it would be good to get this addressed upstream.
Should be fixed now first in llvm-3.2-1.fc19. Moving bug back to F17 and building llvm-3.1-13.1.fc18. Backporting the fix to F17 is trivial except that f17 branch is now on 3.1, but f17-updates is still 3.0!
llvm-3.1-13.1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/llvm-3.1-13.1.fc18
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
llvm-3.1-13.1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I'd still like to backport the fix I did for F18 later to F17, but if someone motivated can post the patch against the current srpm and test it that would be helpful.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.