[LLVMdev] Building llvm from source with clang instead of gcc
eldlistmailingz at tropicsoft.com
Sun Jan 6 08:45:37 PST 2013
On 1/6/2013 9:47 AM, Justin Holewinski wrote:
> On Sat, Jan 5, 2013 at 11:08 PM, Edward Diener
> <eldlistmailingz at tropicsoft.com <mailto:eldlistmailingz at tropicsoft.com>>
> On 1/5/2013 8:01 PM, Justin Holewinski wrote:
> On Sat, Jan 5, 2013 at 5:59 PM, Edward Diener
> <eldlistmailingz at tropicsoft.__com
> <mailto:eldlistmailingz at tropicsoft.com>
> <mailto:eldlistmailingz at __tropicsoft.com
> <mailto:eldlistmailingz at tropicsoft.com>>>
> On 01/05/2013 01:11 PM, Dmitri Gribenko wrote:
> On Sat, Jan 5, 2013 at 7:48 PM, Edward Diener
> <eldlistmailingz at tropicsoft.____com
> <mailto:eldlistmailingz at __tropicsoft.com
> <mailto:eldlistmailingz at tropicsoft.com>>> wrote:
> I actually found out that llvm/configure will
> choose clang
> if it is
> found in the path. This contradicts what is written at
> where it says it
> will use the first GCC it finds. Perhaps that
> needs to be
> Updated docs in r171630.
> Finally I found that if llvm/configure uses clang
> instead of
> gcc, it
> invariably fails on my Linux distros because it is
> using the gcc
> distributed included directories and an earlier
> version of
> clang will
> often fail with these gcc header files. Once I force
> llvm/configure to
> use gcc, building llvm/clang succeeds again.
> Right. Maybe we need to skip old clang versions in
> this case.
> I think this should be done until clang can use its own
> header files
> and libraries, when it is installed as a binary, rather
> than the
> ones that gcc installs. In fact I am a bit amazed that
> clang does
> not already have its own header files and libraries for use
> when one
> tries llvm/configure and it sets up llvm's build system to
> use clang
> as its compiler. Is this the fault of clang or is it the
> fault of
> the llvm/configure system ?
> There is no complete solution for LLVM-only headers/libraries yet on
> Linux. For C++, you can use libc++, but you still need some GCC
> libraries (or alternatives). And you will at least need glibc or
> another compatible C runtime.
> Should not what it is needed by clang to work correctly under Linux
> be posted somewhere on the clang Getting Started web page ? Even
> what you posted above requires guesswork on my part.
> 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.
I do not believe this should ever happen. I am not focusing blame but
simply saying that from an end-user's POV this is not acceptable if one
wants to use clang without having to build it oneself.
> Am I supposed to install libc++ and glibc in a Linux distro for
> clang to work correctly ?
> glibc will already be there. libc++ is purely optional. Clang will
> happily use libstdc++ (which comes with your linux distribution), but
> newer libstdc++ versions may use new GCC extensions that clang does not
> yet support. This is an unfortunate condition that arises from
> depending on GNU libraries that assume GCC. At this time, libc++ is not
> entirely self-contained on Linux and still requires some GCC libraries
> for some external functions.
> Which versions do I need ?
> I'm guessing you are running into issues with the C++ standard library
> headers. In that case, it depends on which clang version you are using.
> For compatibility reasons, it is best to always use the latest
> released clang (if not trunk). If you try again with 3.2, I bet your
> problems go away.
> How do I tell clang what to use or is this automatically figured out
> by clang ?
> There are ways to override the location for the headers/libraries of
> libstdc++, but I would not recommend this. Upgrading to a newer clang
> should be easier in the long run.
> Will llvm/configure use these libraries if I let it choose a clang
> binary in order to build the latest llvm/clang from source ?
> Which libraries? An older libstdc++? You can use CXXFLAGS and LDFLAGS
> to adjust the library search paths, just as you use CXX to set the
> compiler to use.
> 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
> This should solve your problem.
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 ? Or is "Install new clang" more complicated than
Originally I thought I could have both an earlier binary version of
clang as well as the latest built version of clang in a Linux distro so
that I could test code on both for compatibility of my library for
end-users. But with the fairly common breakage of the binary version
package of clang when libstdc++/glibc gets updated, this has become much
less of a reality.
More information about the llvm-dev