[llvm-dev] A libc in LLVM

[Michael Spencer via llvm-dev]

On Fri, Jul 12, 2019 at 12:29 PM Rich Felker via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Fri, Jul 12, 2019 at 02:54:40PM -0400, Siva Chandra wrote:
> > * A large hole in the llvm toolchain will be plugged with this new
> > libc.
>
> I read this as a confirmation of my concerns from my previous post and
> tweets, that this looks like you're trying to make "LLVM libc" (or
> rather "Google libc") the first-class libc for use with clang/LLVM,
> radically altering the boundaries between tooling and platform, and
> relegating the existing libc implementations on LLVM's targets to
> second-class.
>
> If this is not the case, can you explain what guarantees we have that
> this is not what's going on?
>

I'm surprised that you would think this given the rest of the llvm project.

We have:

* clang, yet all of llvm still builds with gcc, msvc, icc, edg, etc...
* lldb, yet you can still debug llvm produced binaries with gdb, and even
msvc's debugger.
* lld, yet you can still link with gnu-ld, gold, link.exe, ld64.
* libc++, yet clang still works with libstdc++, dinkumware, and the msvc
stdlib.
* libc++abi, yet libc++ still works with libsupc++ and other c++ abi libs.
* libunwind, yet libc++abi works with other unwinders.
* compiler-rt (builtins), yet you can still use libgcc.
* compiler-rt (sanitizers), yet gcc uses them.

It has been well proven that llvm project alternatives do not push out or
harm non-llvm compatibility.  We even cooperate with non-llvm projects on
changes and new features where it makes sense.

What makes you think a llvm libc would be any different?

- Michael Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190712/76d1f4a4/attachment.html>