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

Sat Jan 5 20:15:40 PST 2013

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.

>
>
> _______________________________________________
> cfe-users mailing list
> cfe-users at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users