<div class="gmail_quote">On Thu, May 31, 2012 at 5:39 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@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 style="word-wrap:break-word"><br><div><div class="im"><div>On May 31, 2012, at 1:20 PM, Chandler Carruth wrote:</div><br></div><blockquote type="cite"><div class="gmail_quote"><div class="im">On Thu, May 31, 2012 at 1:13 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 31 May 2012 05:02, Alexey Samsonov <<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>> wrote:<br>
> Hi,<br>
><br>
> tl;dr How can I include LLVM headers and use code from libLLVM*.a files when<br>
> building compiler-rt libraries?<br>
<br>
</div>LLVM and compiler-rt  have different licenses (compiler-rt is dual<br>
licensed with the MIT license). Would that be a problem?<br></blockquote><div><br></div></div><div>This is a good point…</div></div></blockquote><div><br></div><div>Yes it is, it would be a problem :-(</div><div class="im">
<div><br></div><blockquote type="cite"><div class="gmail_quote"><div>Chris, I'm wondering whether putting all of the runtimes into 'compiler-rt' is really the best structure at this point... What would seem a somewhat less awkward fit to me these days:</div>

<div><br></div><div>- a runtimes project which contains various runtime libraries, under the usual LLVM license</div><div>- the original 'compiler-rt' bits either as a sub-library of this which happens to be buildable stand-alone and dual-licensed, or as its own entirely separate project</div>

<div>- coverage profile runtime, asan, tsan, and common runtime libraries separated out from compiler-rt</div><div><br></div><div><br></div><div>We can achieve the same technical result with the current structure, but its inverted and awkward: the restrictive rules (dual license / stand-alone build) are enforced in an outer layer, with the permissive rules returning in an inner layer (the asan or tsan runtimes themselves).</div>

<div><br></div><div>Thoughts?</div><div><br></div><div>If this is the direction to go, I'm happy to do the lion share of leg work to re-organize (with the help of ASan folks)... I think my personal preference would be for compiler-rt to be a separate top-level project from a generic 'runtimes' project.</div>

</div>
</blockquote></div></div><br><div>I'm not sure that this solves the problem.  The reason we have dual licenses for the runtime stuff is that we don't want the UIUC license (which has a binary attribution clause) to affect stuff built with the compiler.  Saying that "clang -fasan produces code that has to binary attribute the LLVM license" is pretty lame.</div>
</div></blockquote><div><br></div><div>I think that what is *traditionally* thought of as compiler-rt has different needs from ASan/TSan/etc. The latter runtimes are really intended to be separate units from the binary; for example none of their code would ever be directly emitted into a function, etc. Certainly the scope and complexity of them are very different, and so it might still make sense to split these into two groups of runtime libraries.</div>
<div><br></div><div>Were I drawing an arbitrary line, I would draw it around the runtime libraries which are stand-alone and implement an available spec for which other implementations can and do exist. (libgcc, libstdc++, etc etc.) Regardless of licensing issues, I suspect making this bucketing more clear would simplify some of these projects....</div>
<div><br></div><div><br></div><div>Anyways, there seem to be a few, all somewhat bad options left to us with ASan/TSan and similar more "advanced" runtimes:</div><div><br></div><div>1) Swallow the lame binary attribution clause requirement. Document this noisily.</div>
<div>2) Require they are build as DSOs, and thus the attribution restricted to that runtime library entity.</div><div>3) Build the functionality needed by ASan/TSan/etc independently of LLVM's core libraries. Code duplication here, and only a dim hope that we could package in a way that lldb or others might be able to shift to depend upon the dual-licensed functionality rather than the core LLVM functionality.</div>
<div>4) Start moving core LLVM libraries into a separate 'core library' or 'common library' project which has the dual-license requirement, but is a "lower-level" component than LLVM itself.</div>
<div><br></div><div>#1 and #2 are at least clear in how they would work. They have downsides, but not in terms of implementation.</div><div><br></div><div>#3 seems like painting ourselves into a corner, and borrowing a lot of technical debt in the future. I suspect we'll keep having to replicate functionality here.</div>
<div><br></div><div>#4 is interesting, but a *ton* of work. The Object library, most of Support and System, all would have to sink into this core module, all would have to get dual-licensed (ow!!! how? some of the contributors are around to agree to new license, but not all... likely a fair amount of rewrite required to produce new versions of libraries under the correct license).</div>
</div>