Building LLVM+Clang with Clang+libc++

I'm attempting to selfhost clang (& libc++) & running into what I
assume are some fairly simple problems (on Ubuntu linux - after using
symlinks to work around some weird binary/include placement in
Ubuntu). Running the following configure command:

    ../../../../llvm/configure --enable-optimized --disable-assertions
--prefix=/home/dblaikie/Development/llvm/clean/install/x86-32/Release/llvm
--with-built-clang CXXFLAGS=-stdlib=libc++

I have previously configured this same path without clang (same
command, bar the last two arguments), built, installed, and built
libc++ from that installed build (libc++ is 'installed' as per the
recommendations - symlinking into the system paths, so it should be
accessible. My simple command line experiments seem to confirm this).

My intent is to reconfigure as above, rebuild, reinstall, rebuild
libc++, and at that point I should be fully self hosting on a clang
build built with clang/libc++.

When I run the above configure command, I get the attached config.log.
The final few lines of output are:

configure:13392: checking LLVM capable compiler
configure:13410: result: clang
configure:13415: checking tool compatibility
configure:13438: error: g++|clang++|icc required but not found

Looking at the configure script itself I'm having difficulty
understanding how it checks for clang. The if check that is failing &
printing this error checks only GXX and IXX, nothing clang related,
but I assume somewhere along the way the clang & gcc paths are merged
given clang's drop-in-replacement-for-gcc design, but I can't find
that point.

Any pointers to documentation on how to do this would be great.

Thanks,
- David

config.log (72.5 KB)

David,

../../../../llvm/configure --enable-optimized --disable-assertions
--prefix=/home/dblaikie/Development/llvm/clean/install/x86-32/Release/llvm
--with-built-clang CXXFLAGS=-stdlib=libc++

I guess --with-build-clang would be useless Was it for testing
llvm-gcc(or similar)?
Did you try "CC=/path/to/clang CXX=/path/to/clang++"?

FYI, I had succeeded to build and test selfhost clang+libcxx on
x86_64-centos5-linux.
(It was a few months ago and I have not tried later)

...Takumi

../../../../llvm/configure --enable-optimized --disable-assertions
--prefix=/home/dblaikie/Development/llvm/clean/install/x86-32/Release/llvm
--with-built-clang CXXFLAGS=-stdlib=libc++

I guess --with-build-clang would be useless Was it for testing
llvm-gcc(or similar)?
Did you try "CC=/path/to/clang CXX=/path/to/clang++"?

Actually I hadn't - I guess I'd assumed that the build needed all
sorts of other tools & was hoping these --with-* build related
arguments would find them altogether. But CC/CXX seems to have worked
sufficiently (I added a break in, just to check I got clang errors
out). I'm not sure how to check that it's actually using libc++ (I
suppose I could break one of the libc++ headers & see what happens, or
access a non-existent member of an standard template & see which
headers it points to)

& if anyone else happens to know about whether those
--with-built-clang & similar arguments are actually meant to work &
how they're meant to work, I'm all ears.

Thanks for the help, Nakamura.

- David

I'm not sure how to check that it's actually using libc++ (I
suppose I could break one of the libc++ headers & see what happens, or
access a non-existent member of an standard template & see which
headers it points to)

So I added a simple break ("std::copy(1, 2, 3)") to see which stdlib
my build was using (when I configured it with CC=/path/to/clang
CXX=/path/to/clang++ CXXFLAGS=-stdlib=libc++) & it seems to still be
using libstdc++, not libc++. I can run "make CXXFLAGS=-stdlib=libc++"
& I get errors in the relevant headers, but I was hoping to get that
baked into my build options.

Any ideas how I could specify this to the configure command/bake it
into the build?

[bonus question: is there a way I can change the default stdlib to
libc++? I suppose I could just edit clang to do so, but I'm curious if
there's an environment variable or otherwise that clang++ itself will
pick up on to decide which stdlib to use. (I assume CXXFLAGS isn't
read by clang++ itself, but merely passed to it by tools like make,
etc)]

Thanks again,
- David

Probably not the cleanest way to do it, but you can pass the -stdlib flag directly when defining CXX:

CXX="/path/to/clang++ -stdlib=libc++"

-- Jean-Daniel

FWIW I decided to test your scenario under Debian Sid:

Here are the knowns:

  1. I have clang/clang++ installed under /usr/local/bin

  2. I have cmake built libc++ installed under /usr/local/include/c++/v1

  3. I built the prior build for libc++ outside of trunk under my LLVMProject path

  4. I have ~/DeveloperProjects/LLVMProjects/trunk/llvm, ~/DeveloperProjects/LLVMProjects/trunk/llvm/projects/llvm-test/ and ~/DeveloperProjects/LLVMProjects/trun/llvm/toosl/clang followed by

  5. ~/DeveloperProjects/LLVMProjects/libc++ outside of the trunk tree

  6. I build LLVM/Clang trunk with standard automake tools

  7. I build libc++ with cmake separately

  8. System CPU Architecture is just a Pentium D 945 on this build box.

  9. I run $ make -j3 (n+1 cores)

  10. If it fails to fully build just run make -j(n+1) until the sections waiting on prior built portions are built

New Scenario includes your request to build LLVM/Clang/Clang++ against libc++

Configuration trick to get it to build my set up is as follow:

$ …/trunk/llvm/configure && …/trunk/llvm/configure --enable-target=x86_64,arm,cpp,cbe --with-clang=/usr/local/bin/clang --with-built-clang --enable-pic --enable-polly --enable-shared --with-cxx-include-arch=x86_64 --enable-optimized --with-optimize-option=-O2 --enable-assertions --disable-bootstrap --disable-multilib --enable-jit --enable-threads --no-create --no-recursion CXX=’/usr/local/bin/clang++’ CXXFLAGS=’-stdlib=libc++ -I/usr/local/include/c++/v1’

What’s in bold is my updated configure set up to include your scenario. What’s in bold is the trick to get automake to make the config.status prepped to build against clang.

Build results:


llvm[2]: Linking Release+Asserts unit test ADT (without symbols)
llvm[2]: ======= Finished Linking Release+Asserts Unit test ADT (without symbols)
make[2]: Leaving directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/unittests/ADT' make[1]: Leaving directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/unittests’
make[1]: Entering directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects' make[2]: Entering directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample’
make[3]: Entering directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/lib' make[4]: Entering directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/lib/sample’
llvm[4]: Compiling sample.c for Release+Asserts build
llvm[4]: Building Release+Asserts Archive Library libsample.a
make[4]: Leaving directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/lib/sample' make[3]: Leaving directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/lib’
make[3]: Entering directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/tools' make[4]: Entering directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/tools/sample’
llvm[4]: Compiling main.c for Release+Asserts build
llvm[4]: Linking Release+Asserts executable Sample (without symbols)
llvm[4]: ======= Finished Linking Release+Asserts Executable Sample (without symbols)
make[4]: Leaving directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/tools/sample' make[3]: Leaving directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/tools’
make[2]: Leaving directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample' make[1]: Leaving directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects’
make[1]: Entering directory /home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/bindings' make[1]: Nothing to be done for all’.
make[1]: Leaving directory `/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/bindings’
llvm[0]: ***** Completed Release+Asserts Build
mdriftmeyer@horus:~/DeveloperProjects/LLVMProject/build-llvm-clang-libc++$

SUCCESS!

Final Conclusion:

I’ll continue to stagger the build of trunk and update libc++ and rebuild trunk for the time being until LLVM/Clang’s Hinnant recommends moving it under the llvm trunk branch directly.

Sincerely Yours,

Marc J. Driftmeyer

This is what I’ve got while having llvm/clang self-hosted with libc++:

[ 1%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o
In file included from /home/ryuta/devel/llvm/src/llvm/lib/Support/Signals.cpp:30:
/home/ryuta/devel/llvm/src/llvm/lib/Support/Unix/Signals.inc:31:10: fatal error:
‘cxxabi.h’ file not found
#include <cxxabi.h>
^
1 error generated.
make[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o] Error 1

which makes sense because libc++ doesn’t come with cxxabi.
Using -std=libc++, there’re supposed to be no cxxabi.h in the search paths of clang:

[ryuta@oroppas]$ clang++ -stdlib=libc++ -v ./main.cpp
clang version 3.0 (trunk 136773)
Target: x86_64-unknown-linux-gnu
Thread model: posix
“/usr/bin/clang-3.0” -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name main.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/…/lib/clang/3.0 -stdlib=libc++ -fdeprecated-macro -ferror-limit 19 -fmessage-length 159 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-TRNrTc.o -x c++ ./main.cpp
clang -cc1 version 3.0 based upon llvm 3.0 hosted on x86_64-unknown-linux-gnu
ignoring nonexistent directory “/usr/include/x86_64-linux-gnu”
ignoring nonexistent directory “/usr/include/i686-linux-gnu/64”
ignoring nonexistent directory “/usr/include/i486-linux-gnu/64”
#include “…” search starts here:
#include <…> search starts here:
/usr/include/c++/v1
/usr/local/include
/usr/bin/…/lib/clang/3.0/include
/usr/include
End of search list.
“/usr/bin/ld” --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/…/…/…/…/lib/crt1.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/…/…/…/…/lib/crti.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/crtbegin.o -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/…/…/…/…/lib -L/lib/…/lib -L/usr/lib/…/lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/…/…/… /tmp/cc-TRNrTc.o -lc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/crtend.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/…/…/…/…/lib/crtn.o

I don’t know if there would be any straightforward fix. libcxxabi is still in its infancy.
Having symbolic links in /usr/include/c++/v1 pointing to /usr/include/c++/4.6.1/cxxabi.h, etc.
might be a solution, but it looks ugly to me.

Regards,

Ryuta

This is what I've got while having llvm/clang self-hosted with libc++:
[ 1%] Building CXX object
lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o
In file included from
/home/ryuta/devel/llvm/src/llvm/lib/Support/Signals.cpp:30:
/home/ryuta/devel/llvm/src/llvm/lib/Support/Unix/Signals.inc:31:10: fatal
error:
'cxxabi.h' file not found
#include <cxxabi.h>
^
1 error generated.
make[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o] Error 1
which makes sense because libc++ doesn't come with cxxabi.
Using -std=libc++, there're supposed to be no cxxabi.h in the search paths
of clang:
[ryuta@oroppas]$ clang++ -stdlib=libc++ -v ./main.cpp
clang version 3.0 (trunk 136773)
Target: x86_64-unknown-linux-gnu
Thread model: posix
"/usr/bin/clang-3.0" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj
-mrelax-all -disable-free -main-file-name main.cpp -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -momit-leaf-frame-pointer -v -resource-dir
/usr/bin/../lib/clang/3.0 -stdlib=libc++ -fdeprecated-macro -ferror-limit 19
-fmessage-length 159 -fcxx-exceptions -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-TRNrTc.o -x c++ ./main.cpp
clang -cc1 version 3.0 based upon llvm 3.0 hosted on
x86_64-unknown-linux-gnu
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/include/i686-linux-gnu/64"
ignoring nonexistent directory "/usr/include/i486-linux-gnu/64"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/v1
/usr/local/include
/usr/bin/../lib/clang/3.0/include
/usr/include
End of search list.
"/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o a.out
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../lib/crt1.o
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../lib/crti.o
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/crtbegin.o
-L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1
-L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../..
/tmp/cc-TRNrTc.o -lc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/crtend.o
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../lib/crtn.o
I don't know if there would be any straightforward fix. libcxxabi is still
in its infancy.
Having symbolic links in /usr/include/c++/v1 pointing to
/usr/include/c++/4.6.1/cxxabi.h, etc.
might be a solution, but it looks ugly to me.

Yep, I hit exactly the same thing when I used the
CXXFLAGS=-stdlib=libc++ argument to make (since I couldn't figure out
how to bake it in via configure). Unless someone's got some well
founded/tested/practiced/etc ideas about how to use libc++
(specifically this issue of libc++abi or alternatives) when building
clang/LLVM I think I'll settle for libstdc++ in my builds for now.

Thanks everyone for helping/trying/confirming things,

- David

New Scenario includes your request to build LLVM/Clang/Clang++ against
libc++

Configuration trick to get it to build my set up is as follow:

$ ../trunk/llvm/configure && ../trunk/llvm/configure
--enable-target=x86_64,arm,cpp,cbe --with-clang=/usr/local/bin/clang
--with-built-clang --enable-pic --enable-polly --enable-shared
--with-cxx-include-arch=x86_64 --enable-optimized --with-optimize-option=-O2
--enable-assertions --disable-bootstrap --disable-multilib --enable-jit
--enable-threads --no-create --no-recursion CXX='/usr/local/bin/clang++'
CXXFLAGS='-stdlib=libc++ -I/usr/local/include/c++/v1'

...

SUCCESS!

I experienced similar success with a similar, though simpler, command
line, but on further experimentation it turns out that the CXXFLAGS
passed to configure weren't then used in the build itself. (you can
confirm this by adding some broken STL usage to any of the LLVM code -
I used "std::copy(1, 2, 3)"). If the compilation error points to
libc++ headers, you win, if not - you're in the same state I was.

To get LLVM to actually build with libc++ at least as an experiment, I
tried passing the same CXXFLAGS to the make command itself - this hit
the libc++abi issue that Ryuta mentioned.

I haven't tried building/using libc++abi as yet - I checked it out but
didn't find any build steps, Makefiles, etc. The website has no howto.
I assume it's just not finished/mature enough yet.

- David

on Ubuntu linux - after using
symlinks to work around some weird binary/include placement in
Ubuntu

To come back to this point as a tangent to the main thread - is it
just me, or is clang broken on Ubuntu? The workaround was simple, but
I'm wondering if there was something obvious I missed.

Step 1) Lib directories.
The big if/else block in tools/clang/lib/Driver/ToolChains.cpp:1500
doesn't seem to work on Ubuntu as it puts the triple twice in the gcc
path. For example crtbegin.o is
    /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.4/crtbegin.o (
http://packages.ubuntu.com/search?searchon=contents&keywords=crtbegin.o&mode=exactfilename&suite=natty&arch=any
)
Whereas on Debian, the file location looks like it'd be one that
clang's code would find:
    /usr/lib/gcc/i486-linux-gnu/4.4/crtbegin.o (
http://packages.debian.org/search?searchon=contents&keywords=crtbegin.o&mode=path&suite=stable&arch=any
)

I worked around this by adding a symlink /usr/lib/gcc ->
/usr/lib/i386-linux-gnu/gcc

It looks like there might be one case of the Ubuntu layout supported,
under x86_64, line 1555 of ToolChains.cpp
(/usr/lib/x86_64-linux-gnu/gcc) - perhaps I should just add a similar
case for other architectures?

Step 2) machine specific include paths (asm/errno.h, being the
first/obvious thing that fails when this is wrong)

Again, using Debian as an example that (visual estimate based on clang
source, I haven't run it to confirm), with asm/errno.h in
/usr/include/asm/errno.h I expect clang works fine. (
http://packages.ubuntu.com/search?mode=exactfilename&suite=natty&section=all&arch=any&searchon=contents&keywords=asm%2Ferrno.h
)
But Ubuntu has it in /usr/include/i386-linux-gnu/asm/errno.h & clang
fails to find this path (
http://packages.ubuntu.com/search?mode=exactfilename&suite=natty&section=all&arch=any&searchon=contents&keywords=asm%2Ferrno.h
)

Again, a symlink workaround was to link /usr/include/asm ->
/usr/include/i386-linux-gnu/asm

I haven't looked into the source code enough to see where the include
path is generated to see if there's a reasonable fix, so I'm open to
suggestions.

- David

libc++abi is not yet usable. It lacks a lots of required functions:

http://libcxxabi.llvm.org/spec.html

-- Jean-Daniel

You should be able to build libc++ with libcxxrt:

https://github.com/pathscale/libcxxrt

Please let me know if you encounter any problems.

David

-- Sent from my Cray X1