Failure building llvm/clang from source using binary clang package on Mageia 2

On Mageia 2 I have installed the binary clang package clang3.0-7. When I
tried to build the latest llvm/clang from source using this binary clang
I get this error:

1) In file included from
/home/mgeldiener/vcs/llvm/lib/Support/Signals.cpp:30:
/home/mgeldiener/vcs/llvm/lib/Support/Unix/Signals.inc:32:10: fatal
error: 'cxxabi.h' file not found
#include <cxxabi.h>
         ^
llvm[1]: Compiling Statistic.cpp for Debug+Asserts build
1 error generated.
gmake[1]: ***
[/home/mgeldiener/dev/clang/build/lib/Support/Debug+Asserts/Signals.o]
Error 1
gmake[1]: *** Waiting for unfinished jobs....
gmake[1]: Leaving directory `/home/mgeldiener/dev/clang/build/lib/Support'
gmake: *** [all] Error 1

If I build with gcc, there are no problems.

I think that we have a new entry for our 'unsupported compilers' list.
Please show the output of 'clang -v -fsyntax-only -x c++ /dev/null'.

It looks like Mageia 2 has C++ headers in a directory unknown to
clang. (So basically, clang from the repository is broken...)

Dmitri

I think that we have a new entry for our 'unsupported compilers' list.
Please show the output of 'clang -v -fsyntax-only -x c++ /dev/null'.

'Unsupported list' exists because some compilers are broken. Here the
compiler it not broken per se, it's just broken package, because
someone who packaged it have not tried to actually use the compiler.

The proper solution is:

1. Report the problem to Mageia
2. Add support of paths to clang
or
2.* Patch the mageia clang package

In any case, 3.0 is ancient.

On Mageia 2 I have installed the binary clang package clang3.0-7. When I
tried to build the latest llvm/clang from source using this binary clang
I get this error:

1) In file included from
/home/mgeldiener/vcs/llvm/lib/Support/Signals.cpp:30:
/home/mgeldiener/vcs/llvm/lib/Support/Unix/Signals.inc:32:10: fatal
error: 'cxxabi.h' file not found
#include <cxxabi.h>
         ^
llvm[1]: Compiling Statistic.cpp for Debug+Asserts build
1 error generated.
gmake[1]: ***
[/home/mgeldiener/dev/clang/build/lib/Support/Debug+Asserts/Signals.o]
Error 1
gmake[1]: *** Waiting for unfinished jobs....
gmake[1]: Leaving directory `/home/mgeldiener/dev/clang/build/lib/Support'
gmake: *** [all] Error 1

If I build with gcc, there are no problems.

I think that we have a new entry for our 'unsupported compilers' list.
Please show the output of 'clang -v -fsyntax-only -x c++ /dev/null'.

clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-mageia-linux-gnu
Thread model: posix
"/usr/bin/clang" -cc1 -triple x86_64-mageia-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 -momit-leaf-frame-pointer -v -resource-dir
/usr/bin/../lib/clang/3.0 -fmodule-cache-path /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-mageia-linux-gnu/4.6.3/../../../../include/c++/4.6.3
-internal-isystem
/usr/bin/../lib/gcc/x86_64-mageia-linux-gnu/4.6.3/../../../../include/c++/4.6.3/x86_64-mageia-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/x86_64-mageia-linux-gnu/4.6.3/../../../../include/c++/4.6.3/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 139 -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-mageia-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-mageia-linux-gnu/4.6.3/../../../../include/c++/4.6.3
/usr/bin/../lib/gcc/x86_64-mageia-linux-gnu/4.6.3/../../../../include/c++/4.6.3/x86_64-mageia-linux-gnu
/usr/bin/../lib/gcc/x86_64-mageia-linux-gnu/4.6.3/../../../../include/c++/4.6.3/backward
/usr/local/include
/usr/bin/../lib/clang/3.0/include
/usr/include
End of search list.

It looks like Mageia 2 has C++ headers in a directory unknown to
clang. (So basically, clang from the repository is broken...)

The Gnu C library headers are at
/usr/lib/gcc/x86_64-mageia-linux-gnu/4.6.3/include. This seems to say
that the include search path is wrong and that is why it does not find
cxxabi.h, which is in the Gnu C library header directory.

I agree, but the result for the end user is the same -- the compiler
can not be used.

Dmitri

I would recommend reporting this to the Mageia bugtracker, since this
is the problem with clang packaging for this distribution.

I have updated our documentation in r171729.

Dmitri

Hello Edward,

Here's a patch for ./configure that should detect and reject a broken
clang in your cases. Could you please apply and test on all platforms
that you recently sent bug reports about? You should see a clear
error from ./configure that the selected compiler is broken.

Dmitri

configure-error-on-broken-clang-v1.patch (4.11 KB)

After applying your patch on Mageia 2 and invoking llvm's configure:

Using clang 3.0 I get:

"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 ..."

Using gcc, there is no error.

After applying your patch on Fedora 17 and invoking llvm's configure:

Using clang 3.0 I get:

"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 ..."

Using gcc, there is no error.

After applying your patch on Suse 12.2 and invoking llvm's configure:

Using clang 3.1, which has previously worked, there is no error.

So it looks to me, based on my tests, that your patch is successful. I look forward to this update in llvm on subversion. Thanks for your help on this matter. I will report the broken clang binary installation to Mageia 2 and Fedora 17.

I've committed a slightly different variant of this patch r171975.

Thank you for testing!

Dmitri

Glad to do it. Thanks for addressing this area.

Unfortunately, after an attempt to use the latest 'configure' update on CentOS 6.3 I think your version may be slightly flawed.

I had been able to build clang from source on CentOS 6.3 using clang 2.8-14 that is distributed as a binary. After your update, however, when I run llvm/configure I receive:

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 ...

When I run 'clang -v -fsyntax-only -x c++ /dev/null' I get:

"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 -fsyntax-only -disable-free -disable-llvm-verifier -main-file-name null -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.51.0.2 -v -resource-dir /usr/lib/clang/2.8 -ferror-limit 19 -fmessage-length 144 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -x c++ /dev/null
clang -cc1 version 2.8 based upon llvm 2.8 hosted on x86_64-redhat-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
  /usr/include/c++/4.4.4
  /usr/include/c++/4.4.4/x86_64-redhat-linux
  /usr/include/c++/4.4.4/backward
  /usr/local/include
  /usr/lib/clang/2.8/include
  /usr/include
  /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
End of search list."

It looks to me that clang 2.8-14 does indeed find the necessary header files. Yet you are rejecting it. Also it did build clang successfully before your update.

Finally when I ran 'gmake -j4' and the llvm/configure fails, the 'gmake' does not appear to ever end even if it prints out nothing further to the console screen.

Can you pastebin the config.log file, please? (I think that clang 2.8
did not support __has_include that I used in the test, but I need the
log file to check that it indeed caused the problem.)

Dmitri

It is on pastebin and is called ConfigureLog. I made it private, FWIW.

Please provide a link. I can not find it because it is private.

Anyway, attached is a patch that should allow old clangs that don't
implement __has_include. Please test.

Dmitri

dont-reject-clang-without-has-include-v1.patch (1.22 KB)

It is on pastebin and is called ConfigureLog. I made it private, FWIW.

Please provide a link. I can not find it because it is private.

I copied it to a public paste called ConfigureLogPublic at http://pastebin.com/yaLHmmGk.

Anyway, attached is a patch that should allow old clangs that don't
implement __has_include. Please test.

Thanks ! If not implementing __has_include does not keep the clang package from working correctly, why would it be part of the "configure" script ?

It is on pastebin and is called ConfigureLog. I made it private, FWIW.

Please provide a link. I can not find it because it is private.

I copied it to a public paste called ConfigureLogPublic at http://pastebin.com/yaLHmmGk.

I see that this clang has problems with parsing unwind.h. I don’t understand how does it manage to compile LLVM/Clang.

Anyway, attached is a patch that should allow old clangs that don’t
implement __has_include. Please test.

Thanks ! If not implementing __has_include does not keep the clang package from working correctly, why would it be part of the “configure” script ?

Sorry, I did not quite get it.

Dmitri

            It is on pastebin and is called ConfigureLog. I made it
            private, FWIW.

        Please provide a link. I can not find it because it is private.

    I copied it to a public paste called ConfigureLogPublic at
    http://pastebin.com/yaLHmmGk.

I see that this clang has problems with parsing unwind.h. I don't
understand how does it manage to compile LLVM/Clang.

It did previously without errors but some warnings.

        Anyway, attached is a patch that should allow old clangs that don't
        implement __has_include. Please test.

    Thanks ! If not implementing __has_include does not keep the clang
    package from working correctly, why would it be part of the
    "configure" script ?

Sorry, I did not quite get it.

I don't know what "__has_include" is but evidently it is not necessary for the compiler to successfully be used to build clang from source. So it seems to me that the 'configure' script should still allow that the compiler can be used to build clang without "__has_include".

I tried your latest patch but it still did not allow me to use clang under CentOS 6.3. I still 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 ...