<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 1, 2014 at 6:10 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="im"><div class="gmail_extra"><div class="gmail_quote">
On 1 February 2014 00:44, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><span style="color:rgb(34,34,34)">* One of the interesting things about compiler-rt is the static library to dynamic library migration (e.g. libgcc.a vs libgcc_s.so, or on Darwin libclang_*.a vs libSystem.dylib). If the shared library ships independently from the compiler, then the compiler may need a .a file that can ship with it that contains any support functions not available in a shared library on the target. Currently, it is a very manual process to figure out which functions are needed where.</span><br>
</div>
<br>
* It would be nice if the clang build system could output a list of all possible support functions it might need for compiler being built. That list could drive what parts of compiler-rt need to be built.<br>
<br>
So, to me an ideal build system for compiler-rt would not just compile the snippets of code, it would figure out which snippets to build based on what the compiler needs and what the OS needs/provides.<br></blockquote><div>
</div></div><br></div></div><div class="gmail_extra">Hi Nick,</div><div class="gmail_extra"><br></div><div class="gmail_extra">These features would be great, but I think it's too complex to migrate from what we have today to that scenario and people won't buy-in that easily.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I think the fact that all sanitizers, profilers and possibly unwinders have their libraries in there is a good reason for us to have separate builds of each library and treat "Compiler-RT" as a repository for run-time libraries, rather than a library in itself.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I'm in favour of naming what we call today "compiler-rt" to "libclang" and moving libcxxabi into it as "libunwind" or anything relevant, but to softly migrate the interactions between RT and Clang over time.</div>
</div></blockquote><div><br></div><div>FYI the name "libclang" is already in use <<a href="http://clang.llvm.org/docs/Tooling.html#libclang">http://clang.llvm.org/docs/Tooling.html#libclang</a>>, so a different name would need to be chosen.</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><br></div><div class="gmail_extra">A few steps like:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1. Move libraries in, rename, compile everything everytime</div><div class="gmail_extra">
2. Separate libraries' build systems, disable via flags / arch support (on both clang and rt)</div><div class="gmail_extra">3. Get Clang to list *libraries* needed, and make RT's make system to only build those</div>
<div class="gmail_extra">4. Get Clang to list *functions* needed, and update RT's make system accordingly</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think having step 3 would be amazing, but 2 is already good for all practical purposes. Step 4 is way past *my* needs, but I don't think it's a bad thing to have.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">cheers,</div><div class="gmail_extra">--renato</div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>