Building llvm/clang with another version of clang

Is it possible to build llvm/clang with a previous version of clang installed as a binary ? If so, how do I get llvm/configure to use the binary version of clang rather than gcc to build the latest version of llvm/clang ?

configure (but not CMake) will check for 'clang' in PATH and prefer to
use it instead of 'gcc' or 'cc'. So just ensure that the previous
version of clang is in your PATH.

But please note that sometimes repositories in various distributions
include outdated versions of clang (for example, Ubuntu 12.10 still
ships clang 3.0). I would recommend building clang with the default
system compiler in that case.

Dmitri

Is it possible to build llvm/clang with a previous version of clang
installed as a binary ? If so, how do I get llvm/configure to use the binary
version of clang rather than gcc to build the latest version of llvm/clang ?

configure (but not CMake) will check for 'clang' in PATH and prefer to
use it instead of 'gcc' or 'cc'. So just ensure that the previous
version of clang is in your PATH.

Yes, I discovered this. This contradicts what LLVM has in its own
getting started page at
http://llvm.org/docs/GettingStarted.html#local-llvm-configuration.

But please note that sometimes repositories in various distributions
include outdated versions of clang (for example, Ubuntu 12.10 still
ships clang 3.0). I would recommend building clang with the default
system compiler in that case.

I also found this out. If I try building the latest llvm/clang with
clang 3.0 it fails. It appears that the reason it fails is that it is
trying to use the gcc header files for the standard C++ libraries, which
an earlier version of clang does not accept, and/or it is not finding
standard C libraries.

Doesn't the clang 3.0 binaries ship with its own version of the C++ and
C header files ?

Is it possible to build llvm/clang with a previous version of clang
installed as a binary ? If so, how do I get llvm/configure to use the binary
version of clang rather than gcc to build the latest version of llvm/clang ?

configure (but not CMake) will check for 'clang' in PATH and prefer to
use it instead of 'gcc' or 'cc'. So just ensure that the previous
version of clang is in your PATH.

Yes, I discovered this. This contradicts what LLVM has in its own
getting started page at
http://llvm.org/docs/GettingStarted.html#local-llvm-configuration.

I have updated docs now.

Doesn't the clang 3.0 binaries ship with its own version of the C++ and
C header files ?

No, clang does not include a complete standard library. It does
include a few system headers
(clang-installation-dir/lib/clang/3.3/include), but that is not a
complete standard library.

Dmitri

Is it possible to build llvm/clang with a previous version of clang
installed as a binary ? If so, how do I get llvm/configure to use the binary
version of clang rather than gcc to build the latest version of llvm/clang ?

configure (but not CMake) will check for 'clang' in PATH and prefer to
use it instead of 'gcc' or 'cc'. So just ensure that the previous
version of clang is in your PATH.

Yes, I discovered this. This contradicts what LLVM has in its own
getting started page at
http://llvm.org/docs/GettingStarted.html#local-llvm-configuration.

I have updated docs now.

Thanks !

Doesn't the clang 3.0 binaries ship with its own version of the C++ and
C header files ?

No, clang does not include a complete standard library. It does
include a few system headers
(clang-installation-dir/lib/clang/3.3/include), but that is not a
complete standard library.

That is really a shame. Relying on some version of clang, whether built or distributed as a binary, working with whatever headers and libraries are used with the version of gcc installed does not seem a good way to do things to me. I sincerely hope that clang changes this.

I know it is a ton of work for clang to develop its own headers/libraries but I believe that each clang version should at least be distributed and/or built with a version of gcc's header/libraries with which it is guaranteed to work and that running clang will always use those correct headers/libraries no matter what headers/libraries a particular version of gcc comes with.

Note that GCC doesn't do this either: you'll see that your system has
separate packages for g++ and for libstdc++.

Yet when I tried to build llvm/clang with clang 3.0 in Fedora 17 I received a number of errors along the lines of:

"In file included from /home/fceldiener/vcs/llvm/include/llvm/Support/SwapByteOrder.h:20:
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/limits:1404:27: error: use of undeclared identifier
       '__int128'; did you mean '__int128_t'?
     struct numeric_limits<__int128>
                           ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/limits:1478:36: error: expected '>'
     struct numeric_limits<unsigned __int128>
                                    ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/limits:1478:5: error: cannot combine with previous '(error)'
       declaration specifier
     struct numeric_limits<unsigned __int128>
     ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/limits:1478:44: error: expected unqualified-id
     struct numeric_limits<unsigned __int128>"

Furthermore when I tried to build llvm/clang with clang 3.0 in Mageia2 I received an error of:

"#include "..." search starts here:
#include<...> search starts here:
   /home/mgeldiener/dev/clang/build/include
   /home/mgeldiener/dev/clang/build/lib/Support
   /home/mgeldiener/vcs/llvm/include
   /home/mgeldiener/vcs/llvm/lib/Support
   /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.
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>
           ^
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"

Finally in both cases when I built llvm/clang with gcc instead of clang there were no errors and llvm/clang built successfully.

I could cite yet another case where building llvm/clang with a binary distribution of an earler version of clang also gave errors which stopped the build whereas using gcc worked fine. So there is something about using an earlier version of clang to build llvm/clang which just does not work. If gcc/libstdc++ work fine together and clang/libstdc++ do not work together, there must be some reason which the clang developers should address, or possibley llvm/configure is not setting up a build correctly which works with clang.

Is it possible to build llvm/clang with a previous version of clang
installed as a binary ? If so, how do I get llvm/configure to use the
binary
version of clang rather than gcc to build the latest version of
llvm/clang ?

configure (but not CMake) will check for 'clang' in PATH and prefer to
use it instead of 'gcc' or 'cc'. So just ensure that the previous
version of clang is in your PATH.

Yes, I discovered this. This contradicts what LLVM has in its own
getting started page at
http://llvm.org/docs/GettingStarted.html#local-llvm-configuration.

I have updated docs now.

Thanks !

Doesn't the clang 3.0 binaries ship with its own version of the C++ and
C header files ?

No, clang does not include a complete standard library. It does
include a few system headers
(clang-installation-dir/lib/clang/3.3/include), but that is not a
complete standard library.

That is really a shame. Relying on some version of clang, whether built
or
distributed as a binary, working with whatever headers and libraries are
used with the version of gcc installed does not seem a good way to do
things
to me. I sincerely hope that clang changes this.

I know it is a ton of work for clang to develop its own headers/libraries
but I believe that each clang version should at least be distributed
and/or
built with a version of gcc's header/libraries with which it is
guaranteed
to work and that running clang will always use those correct
headers/libraries no matter what headers/libraries a particular version
of
gcc comes with.

Note that GCC doesn't do this either: you'll see that your system has
separate packages for g++ and for libstdc++.

Yet when I tried to build llvm/clang with clang 3.0 in Fedora 17 I received
a number of errors along the lines of:

"In file included from
/home/fceldiener/vcs/llvm/include/llvm/Support/SwapByteOrder.h:20:
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/limits:1404:27:
error: use of undeclared identifier
      '__int128'; did you mean '__int128_t'?
    struct numeric_limits<__int128>
                          ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/limits:1478:36:
error: expected '>'
    struct numeric_limits<unsigned __int128>
                                   ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/limits:1478:5:
error: cannot combine with previous '(error)'
      declaration specifier
    struct numeric_limits<unsigned __int128>
    ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/limits:1478:44:
error: expected unqualified-id
    struct numeric_limits<unsigned __int128>"

Furthermore when I tried to build llvm/clang with clang 3.0 in Mageia2 I
received an error of:

"#include "..." search starts here:
#include<...> search starts here:
  /home/mgeldiener/dev/clang/build/include
  /home/mgeldiener/dev/clang/build/lib/Support
  /home/mgeldiener/vcs/llvm/include
  /home/mgeldiener/vcs/llvm/lib/Support
  /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.
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>
          ^
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"

Finally in both cases when I built llvm/clang with gcc instead of clang
there were no errors and llvm/clang built successfully.

I could cite yet another case where building llvm/clang with a binary
distribution of an earler version of clang also gave errors which stopped
the build whereas using gcc worked fine. So there is something about using
an earlier version of clang to build llvm/clang which just does not work. If
gcc/libstdc++ work fine together and clang/libstdc++ do not work together,
there must be some reason which the clang developers should address, or
possibley llvm/configure is not setting up a build correctly which works
with clang.

My point was simply that GCC doesn't ship a standard library
implementation with it and nor does/will Clang. Some versions of Clang
work with some versions of libstdc++ (& some versions of libc++). Most
of the Clang developers pay careful attention to compatibility with
one stdlib implementation on one platform (the Apple folks worry about
Clang+OSX+libc++, but not all variations/combinations, for example).
The people making Clang packages for the various Linux distributions
you've tried are often not Clang developers nor providing test
infrastructure to report failures of reasonable test cases back to the
developers. That would be useful.

Essentially what I'm saying is:
* Clang won't ship a stdlib implementation with it.
* Distributions/packages of Clang should
  * be better tested (& ideally that testing rolled up/reported to
Clang developers)
  * have appropriate dependencies on compatible stdlib implementations
(not sure how package owners would want to handle this - it might be
weird if the clang package had a strong dependency on libstdc++
because someone might be using Clang only to build C programs (whereas
it makes sense for the g++ package to have a strong dependence on a
compatible libstdc++ implementation))

Hopefully that's a bit more clear.

It is clearer. Thanks !

It does appear that the clang binary distros do not create a dependency against a particular version of the standard library and this causes serious problems. But I understand that it is not necessarily the clang developers problems but rather tha problem of the package creators of clang for a particular distro.