[LLVMdev] Building llvm from source with clang instead of gcc
Edward Diener
eldlistmailingz at tropicsoft.com
Sun Jan 6 11:56:12 PST 2013
On 01/06/2013 01:36 PM, Óscar Fuentes wrote:
> Edward Diener <eldlistmailingz at tropicsoft.com> writes:
>
>>> Clang will attempt to use your installed system libraries, usually
>>> libstdc++ and glibc on a Linux distribution. We could probably maintain
>>> a libstdc++ compatibility table that says clang x.y is compatible with
>>> libstdc++ up to z.w. In the vast majority of cases, this just works if
>>> you install a somewhat-newer version of clang. The problems arise when
>>> you use an older clang with a newer libstdc++ (e.g. newer gcc and/or
>>> linux distribution).
>>
>> This is what evidently happens. A clang binary distribution gets
>> created for a particular Linux distro but there is no compatibility in
>> the package which states that it only works with some version of
>> libstdc++ or glibc or earlier. Then a later version of gcc gets
>> installed and with it a later version of libstdc++ and glibc as a
>> dependency. Now the binary version of clang no longer works on that
>> system because of the updates to the C/C++ standard library.
>
> Then, the package system of your Linux distribution is broken. Or the
> package containing the Clang binaries does not correctly state its
> dependencies.
The package does state its dependencies and in the case I am now looking
at, in Fedora 17, says that clang3.0 it was upgraded for compatibility
with gcc4.7.2. When I tried to build llvm/clang itself using the
clang3.0 package on Fedora 17 I received the error:
"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>"
When I used gcc4.7.2 to build llvm/clang I had no problems.
On other Linux distros I had other errors. I will report each one here
in separate threads. I had originally reported the error above in the
clang user mailing list.
>
> [snip]
>
>>> Generally, it is recommended to bootstrap clang:
>>>
>>> 1. Build llvm/clang with system gcc
>>> 2. Build llvm/clang with new clang
>>> 3. Install new clang somewhere (which will automatically use system
>>> libstdc++/glibc).
>>>
>>> This should solve your problem.
>
> [I think Justin's recipe is overkill, but whatever]
>
>> OK, this sounds good. Can this process not be explained on the clang
>> Getting Started page for those who are building clang from source. I
>> am not sure how step 3) is supposed to go. Do I just copy the built
>> bin directory somewhere else and then put it first in my PATH, before
>> running llvm/configure ?
>
> You can install on a temporary directory or directly use the newly
> created clang binaries, setting the environment variables CC and CXX
> with full paths like this:
>
> CC=/path/to/clang CXX=/path/to/clang++ configure [configure options] && make
>
> Changing the PATH should work, but remeber to undo the change
> afterwards.
>
>> Or is "Install new clang" more complicated than that ?
>
> It is simply `sudo make install' (which installs on system-level default
> directories.) You can also install on a custom directory, using the
> parameter `--prefix=' in the `configure' invocation.
Thanks for this information
More information about the llvm-dev
mailing list