[cfe-users] Building llvm/clang with another version of clang

[Edward Diener]

On 1/5/2013 7:30 PM, David Blaikie wrote:
> On Sat, Jan 5, 2013 at 3:08 PM, Edward Diener
> <eldlistmailingz at tropicsoft.com> wrote:
>> On 01/05/2013 01:18 PM, Dmitri Gribenko wrote:
>>>
>>> On Sat, Jan 5, 2013 at 7:58 PM, Edward Diener
>>> <eldlistmailingz at tropicsoft.com>  wrote:
>>>>
>>>> On 01/05/2013 09:16 AM, Dmitri Gribenko wrote:
>>>>>
>>>>> On Sat, Jan 5, 2013 at 7:31 AM, Edward Diener
>>>>> <eldlistmailingz at tropicsoft.com>  wrote:
>>>>>>
>>>>>> 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.