[cfe-users] Building llvm/clang with another version of clang
Edward Diener
eldlistmailingz at tropicsoft.com
Sun Jan 6 05:21:30 PST 2013
On 01/05/2013 11:15 PM, David Blaikie wrote:
> On Sat, Jan 5, 2013 at 7:57 PM, Edward Diener
> <eldlistmailingz at tropicsoft.com> wrote:
>> 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.
>
> 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.
More information about the cfe-users
mailing list