<div dir="ltr"><div dir="ltr">On Tue, Jun 25, 2019 at 1:18 AM Fāng-ruì Sòng <<a href="mailto:maskray@google.com" target="_blank">maskray@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Some natural questions:<br><br>1) Will libm be included?<br></div></blockquote><div><br></div><div>Yes, libm and libpthread are absolutely included. Further, [r]crt*.o files which support static linking of all kinds are also included.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">2) How will llvm libc be different from musl in design perspectives?</div></blockquote><div><br></div><div>I have listed our rough goals here: <a href="http://lists.llvm.org/pipermail/llvm-dev/2019-June/133360.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2019-June/133360.html</a> </div><div>We want llvm libc design to accommodate them from the start.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Then another natural question is how the kernel differences will be effectively isolated. The platform specific macros in compiler-rt may be a bit messy now. I hope we can prevent that situation.</div></blockquote><div><br></div><div>We definitely want to avoid "mess". But at the same time, it's hard to talk about this in a general fashion. We will have to take this up on a case by case basis and discuss at a narrower scope as to what makes the most practical sense.</div></div></div>