<div>This is what I've got while having llvm/clang self-hosted with libc++:</div><div><br></div><div>[  1%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o</div><div>In file included from /home/ryuta/devel/llvm/src/llvm/lib/Support/Signals.cpp:30:</div>
<div>/home/ryuta/devel/llvm/src/llvm/lib/Support/Unix/Signals.inc:31:10: fatal error: </div><div>      'cxxabi.h' file not found</div><div>#include <cxxabi.h></div><div>         ^</div><div>1 error generated.</div>
<div>make[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o] Error 1</div><div><br></div><div>which makes sense because libc++ doesn't come with cxxabi.</div><div>Using -std=libc++, there're supposed to be no cxxabi.h in the search paths of clang:</div>
<div><br></div><div><div>[ryuta@oroppas]$ clang++ -stdlib=libc++ -v ./main.cpp </div><div>clang version 3.0 (trunk 136773)</div><div>Target: x86_64-unknown-linux-gnu</div><div>Thread model: posix</div><div> "/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</div>
<div>clang -cc1 version 3.0 based upon llvm 3.0 hosted on x86_64-unknown-linux-gnu</div><div>ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"</div><div>ignoring nonexistent directory "/usr/include/i686-linux-gnu/64"</div>
<div>ignoring nonexistent directory "/usr/include/i486-linux-gnu/64"</div><div>#include "..." search starts here:</div><div>#include <...> search starts here:</div><div> /usr/include/c++/v1</div>
<div> /usr/local/include</div><div> /usr/bin/../lib/clang/3.0/include</div><div> /usr/include</div><div>End of search list.</div><div> "/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</div>
</div><div><br></div><div>I don't know if there would be any straightforward fix. libcxxabi is still in its infancy.</div><div>Having symbolic links in /usr/include/c++/v1 pointing to /usr/include/c++/4.6.1/cxxabi.h, etc.</div>
<div>might be a solution, but it looks ugly to me.</div><div><br></div><div>Regards,</div><div><br></div><div>Ryuta</div><br><div class="gmail_quote">On Wed, Aug 3, 2011 at 11:19 AM, Marc J. Driftmeyer <span dir="ltr"><<a href="mailto:mjd@reanimality.com">mjd@reanimality.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><u></u>

  
    
  
  <div bgcolor="#ffffff" text="#000000">
    FWIW I decided to test your scenario under Debian Sid:<br>
    <br>
    <big>Here are the knowns:</big><br>
    <br>
    <ol>
      <li>I have clang/clang++ installed under /usr/local/bin</li>
      <li>I have cmake built libc++ installed under
        /usr/local/include/c++/v1</li>
      <li>I built the prior build for libc++ outside of trunk under my
        LLVMProject path</li>
      <li>I have ~/DeveloperProjects/LLVMProjects/trunk/llvm,
        ~/DeveloperProjects/LLVMProjects/trunk/llvm/projects/llvm-test/
        and ~/DeveloperProjects/LLVMProjects/trun/llvm/toosl/clang
        followed by</li>
      <li>~/DeveloperProjects/LLVMProjects/libc++ outside of the trunk
        tree<br>
      </li>
      <li>I build LLVM/Clang trunk with standard automake tools</li>
      <li>I build libc++ with cmake separately<br>
      </li>
      <li>System CPU Architecture is just a Pentium D 945 on this build
        box.</li>
      <li>I run $ make -j3 (n+1 cores)</li>
      <li>If it fails to fully build just run <b>make</b> -j(n+1) until
        the sections waiting on prior built portions are built<br>
      </li>
    </ol>
    <big>New Scenario includes your request to build LLVM/Clang/Clang++
      against libc++</big><br>
    <br>
    <big>Configuration trick to get it to build my set up is as follow:</big><br>
    <br>
      $ <u><b>../trunk/llvm/configure &&</b></u>
    ../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 <b>CXX='/usr/local/bin/clang++'
      CXXFLAGS='-stdlib=libc++ -I/usr/local/include/c++/v1'</b><br>
    <br>
    What's in <b>bold</b> is my updated configure set up to include
    your scenario. What's in <u><b>bold</b></u> is the trick to get
    automake to make the config.status prepped to build against clang.<br>
    <br>
    <big>Build results:</big><br>
    <br>
    ...<br>
    llvm[2]: Linking Release+Asserts unit test ADT (without symbols)<br>
    llvm[2]: ======= Finished Linking Release+Asserts Unit test ADT
    (without symbols)<br>
    make[2]: Leaving directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/unittests/ADT'<br>
    make[1]: Leaving directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/unittests'<br>
    make[1]: Entering directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects'<br>
    make[2]: Entering directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample'<br>
    make[3]: Entering directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/lib'<br>
    make[4]: Entering directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/lib/sample'<br>
    llvm[4]: Compiling sample.c for Release+Asserts build<br>
    llvm[4]: Building Release+Asserts Archive Library libsample.a<br>
    make[4]: Leaving directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/lib/sample'<br>
    make[3]: Leaving directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/lib'<br>
    make[3]: Entering directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/tools'<br>
    make[4]: Entering directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/tools/sample'<br>
    llvm[4]: Compiling main.c for Release+Asserts build<br>
    llvm[4]: Linking Release+Asserts executable Sample (without symbols)<br>
    llvm[4]: ======= Finished Linking Release+Asserts Executable Sample
    (without symbols)<br>
    make[4]: Leaving directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/tools/sample'<br>
    make[3]: Leaving directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample/tools'<br>
    make[2]: Leaving directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects/sample'<br>
    make[1]: Leaving directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/projects'<br>
    make[1]: Entering directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/bindings'<br>
    make[1]: Nothing to be done for `all'.<br>
    make[1]: Leaving directory
`/home/mdriftmeyer/DeveloperProjects/LLVMProject/build-llvm-clang-libc++/bindings'<br>
    llvm[0]: ***** Completed Release+Asserts Build<br>
mdriftmeyer@horus:~/DeveloperProjects/LLVMProject/build-llvm-clang-libc++$<br>
    <br>
    <b>SUCCESS!</b><br>
    <br>
    <br>
    <big>Final Conclusion:</big> <br>
    <br>
    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. <br>
    <br>
    Sincerely Yours,<br>
    <br>
    Marc J. Driftmeyer<div><div></div><div class="h5"><br>
    <br>
    On 08/02/2011 12:14 AM, David Blaikie wrote:
    </div></div><blockquote type="cite"><div><div></div><div class="h5">
      <pre>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
</pre>
      </div></div><pre><fieldset></fieldset>
_______________________________________________
cfe-dev mailing list
<div class="im"><a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a>
</div></pre>
    </blockquote>
    <br>
    <div>-- <br>
      Marc J. Driftmeyer<br>
      Email :: <a href="mailto:mjd@reanimality.com" target="_blank">mjd@reanimality.com</a><br>
      Web :: <a href="http://www.reanimality.com" target="_blank">http://www.reanimality.com</a><br>
      Cell :: <a href="tel:%28509%29%20435-5212" value="+15094355212" target="_blank">(509) 435-5212</a>
    </div>
  </div>

<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br>