<div dir="ltr"><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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><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 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 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>