Bug 893817 - The clang package is not setup to find its headers/libraries correctly
Summary: The clang package is not setup to find its headers/libraries correctly
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: llvm
Version: 17
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-10 01:02 UTC by Edward Diener
Modified: 2013-08-01 16:49 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-01 16:49:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Re-introduce lost --with-c-include-dirs option in the SPEC (326 bytes, patch)
2013-01-28 10:25 UTC, Yury V. Zaytsev
no flags Details | Diff
Test performed by clang configure script (179 bytes, text/x-c++src)
2013-02-09 22:35 UTC, Yury V. Zaytsev
no flags Details

Description Edward Diener 2013-01-10 01:02:20 UTC
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.

Comment 1 Jakub Jelinek 2013-01-10 16:38:07 UTC
Why are you filing clang bugs against gcc?

Comment 2 Yury V. Zaytsev 2013-01-23 16:21:16 UTC
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?

Comment 3 Jens Petersen 2013-01-28 06:06:46 UTC
Any more details?

The above output is not terribly clear to me.
What exactly is expected?

Comment 4 Yury V. Zaytsev 2013-01-28 10:23:59 UTC
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.

Comment 5 Yury V. Zaytsev 2013-01-28 10:25:04 UTC
Created attachment 688846 [details]
Re-introduce lost --with-c-include-dirs option in the SPEC

Comment 6 Edward Diener 2013-01-29 01:26:14 UTC
(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 ?

Comment 7 Yury V. Zaytsev 2013-01-29 07:24:10 UTC
Hi Edward,

What do you mean by that? You recompiled the package with my patch and it's still not working?

--Yury.

Comment 8 Edward Diener 2013-01-30 01:53:51 UTC
(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 ?

Comment 9 Yury V. Zaytsev 2013-01-30 07:36:56 UTC
> 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.

Comment 10 Jens Petersen 2013-02-04 09:55:38 UTC
(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?

Comment 11 Jens Petersen 2013-02-04 10:19:45 UTC
Here is a test build for F18:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4926585

Comment 12 Yury V. Zaytsev 2013-02-04 11:23:10 UTC
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...

Comment 13 Yury V. Zaytsev 2013-02-04 13:06:57 UTC
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.

Comment 14 Jens Petersen 2013-02-05 09:17:59 UTC
Right thanks, Yury - I had just noticed that myself before trying.

Comment 15 Jens Petersen 2013-02-05 11:32:23 UTC
I wonder though if llvm should not BR with %gcc_version too though.

Comment 16 Jens Petersen 2013-02-05 12:37:34 UTC
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?

Comment 17 Jens Petersen 2013-02-05 13:26:28 UTC
Test scratch build for f18 with backported fixes from rawhide:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4929918

Comment 18 Yury V. Zaytsev 2013-02-05 14:07:14 UTC
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?!

Comment 19 Yury V. Zaytsev 2013-02-05 14:17:16 UTC
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.

Comment 20 Jens Petersen 2013-02-06 01:54:49 UTC
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.

Comment 21 Jens Petersen 2013-02-06 02:38:45 UTC
Looks ok to me on x86_64 at least.

Comment 22 Yury V. Zaytsev 2013-02-06 08:04:18 UTC
Fat chance on i386, Jens: ignoring nonexistent directory "/usr/lib/gcc/i386*/4.7.2/include" ...

Comment 23 Jens Petersen 2013-02-07 05:18:11 UTC
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

Comment 24 Yury V. Zaytsev 2013-02-07 08:48:34 UTC
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.

Comment 25 Jens Petersen 2013-02-08 09:32:25 UTC
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

Comment 26 Jens Petersen 2013-02-08 09:35:00 UTC
Would still appreciate a small non-trivial testcase just to check
that this now works correctly.

Comment 27 Jens Petersen 2013-02-08 09:43:41 UTC
Forgot to acknowledge Yury's help.

http://pkgs.fedoraproject.org/cgit/llvm.git/commit/?id=b8204c16e049b4844a05f91206f42e5c40db07c9

Comment 28 Yury V. Zaytsev 2013-02-08 10:49:04 UTC
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.

Comment 29 Edward Diener 2013-02-09 02:38:42 UTC
(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.

Comment 30 Yury V. Zaytsev 2013-02-09 08:48:03 UTC
> 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?

Comment 31 Jens Petersen 2013-02-09 09:23:26 UTC
(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?

Comment 32 Edward Diener 2013-02-09 10:26:50 UTC
(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.

Comment 33 Yury V. Zaytsev 2013-02-09 12:35:42 UTC
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.

Comment 34 Edward Diener 2013-02-09 20:47:42 UTC
(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.

Comment 35 Yury V. Zaytsev 2013-02-09 22:34:53 UTC
> 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.

Comment 36 Yury V. Zaytsev 2013-02-09 22:35:38 UTC
Created attachment 695583 [details]
Test performed by clang configure script

Comment 37 Jens Petersen 2013-02-11 03:41:10 UTC
(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.)

Comment 38 Jens Petersen 2013-02-12 09:23:02 UTC
Hmm, I can't rebuild llvm locally with llvm/clang installed.
Maybe llvm.spec should be configured not to build with itself?

Comment 39 Jens Petersen 2013-02-12 09:54:14 UTC
(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).

Comment 40 Yury V. Zaytsev 2013-02-12 16:47:46 UTC
> 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.

Comment 41 Jens Petersen 2013-02-13 02:05:15 UTC
(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.

Comment 42 Jens Petersen 2013-02-20 08:52:52 UTC
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!

Comment 43 Fedora Update System 2013-02-20 09:26:17 UTC
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

Comment 44 Fedora Admin XMLRPC Client 2013-02-27 15:11:52 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 45 Fedora Update System 2013-03-02 20:12:12 UTC
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.

Comment 46 Jens Petersen 2013-04-04 02:29:06 UTC
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.

Comment 47 Fedora End Of Life 2013-07-04 05:35:32 UTC
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.

Comment 48 Fedora End Of Life 2013-08-01 16:49:46 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.