[cfe-dev] libc++abi

Christopher Bergström cbergstrom at pathscale.com
Tue May 24 10:07:42 PDT 2011


2011/5/24 Chris Lattner <clattner at apple.com>:
>
> On May 24, 2011, at 1:56 AM, 罗勇刚(Yonggang Luo) wrote:
>>
>> 1) It's used in production already
>> 2) It's been tested with LLVM, PathScale and possibly other compilers
>> 3) It's portable across FreeBSD, Linux, Solaris, OSX.. etc
>> 4) Has good inline documentation
>> 5) Smallest/fastest C++ runtime in the industry based on my tests
>>
>> ./C
>>
>> ps. Someone kick me if it's not in the wild by later today
>
> Is that means https://github.com/pathscale/libcxxrt will be merged into
> libc++abi?
>
> Hi Yonggang,
> After discussion, we decided not to do this.  The bulk of libcxxrt is an
> older demangler (that doesn't support C++'0x) that I think they're planning
> to drop.  The rest of the code is relatively minor stuff like implementation
> of std::bad_alloc and a few other glue things that should be
> straight-forward to implement in libc++abi.  Since adding an external
> dependency complicates the licensing and distribution model, we're prefer to
> keep the LLVM libc++abi independent of libcxxrt.

We're going to improve the current demangler code to handle C++0x as
the one in libc++abi is currently bloated and complicated beyond
belief.  (Larger than the whole runtime).

For the record "we" didn't decide to do this at all - it was *you* who
decided this.  *We* (PathScale) are/were very willing to do everything
we could to collaborate and make this work.  Your proposal to fork
libcxxrt based on unspecified future possibilities seemed
unreasonable.

I really see no reason you can't setup a git mirror or something.
People will have to build 2 projects and clone the source from github
vs llvm.org shouldn't be a deal breaker.  Apple is of course free to
do whatever they want, but why duplicate yet another wheel?  (We have
no plans to be a problematic upstream - we're not the FSF)




More information about the cfe-dev mailing list