[cfe-dev] Building LLVM+Clang with Clang+libc++

[David Blaikie]

> 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 at 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