<div dir="auto"><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello LLVM Developers,<br></blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Within Google, we have a growing range of needs that existing libc<br>
implementations don't quite address. This is pushing us to start working on<br>
a new libc implementation.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It would be convenient for LLVM to bundle libc. I've been shipping a subset of musl with LLVM for a while now and based on passing comment at conferences suspect that to be common. The codebase is coherent and adherence to the spec is good.</div><div dir="auto"><br></div><div dir="auto">If we adopt that, even by forking it, then we'd have a solid, multiarch libc with dynamic linking support within a day or so. A bit longer to set up fuzz testing.</div><div dir="auto"><br></div><div dir="auto">I'd be interested to know how that fails to meet the internal requirements at Google, especially in such a way that couldn't be managed as a downstream fork.</div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto"><br></div><div dir="auto">Jon</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>