[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

[Richard Smith]

On Mon, Oct 28, 2013 at 5:53 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> On Mon, Oct 28, 2013 at 5:13 PM, "C. Bergström" <cbergstrom at pathscale.com>wrote:
>
>> On 10/29/13 07:01 AM, Richard Smith wrote:
>>
>>>
>>> [As an aside: I use libc++ for my Clang development (on Ubuntu Linux),
>>> and it works for me (tm). This is with libstdc++ providing the ABI pieces,
>>> rather than libc++abi or libcxxrt, though.]
>>>
>> libc++ "works" for us as well, but it can't self host. I don't know if
>> your "works" and my definition of works is 1:1. Can your clang+libc++ build
>> itself multiple levels deep?
>>
>
> Yes. I use my system g++ for my stage1, I use that compiler to build my
> stage2, and I use my stage2 bootstrapped compiler for all my development
> work. I rebuild my stage2 every few months.
>
> I don't think I've ever explicitly checked that I get stage2 == stage3,
> but stage2 produces working compilers, but I'm doing a full bootstap now
> and I'll let you know when it's done.
>

Just for fun, I used libc++ and libc++abi instead of libc++ and libstdc++.
Bootstrap success, with:

$ ldd ./bin/clang
        linux-vdso.so.1 =>  (0x00007fffbbf3c000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc42f456000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc42f252000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
(0x00007fc42f02a000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fc42ee0d000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc42ebf6000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x00007fc42e90c000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc42e610000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007fc42e3fa000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc42e039000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc42f684000)

I'll do a stage2 / stage3 compare tomorrow, but I'm not expecting any
surprises. (I'm also mildly interested in trying to replace libgcc_s with
compiler_rt and using lld to link, but again, that's for another day...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131028/9d6c3bbf/attachment.html>