[LLVMdev] Using LLVM code in projects/compiler-rt
Chris Lattner
clattner at apple.com
Thu May 31 17:39:25 PDT 2012
On May 31, 2012, at 1:20 PM, Chandler Carruth wrote:
> On Thu, May 31, 2012 at 1:13 PM, Rafael EspĂndola <rafael.espindola at gmail.com> wrote:
> On 31 May 2012 05:02, Alexey Samsonov <samsonov at google.com> wrote:
> > Hi,
> >
> > tl;dr How can I include LLVM headers and use code from libLLVM*.a files when
> > building compiler-rt libraries?
>
> LLVM and compiler-rt have different licenses (compiler-rt is dual
> licensed with the MIT license). Would that be a problem?
>
> This is a good point…
Yes it is, it would be a problem :-(
> 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:
>
> - a runtimes project which contains various runtime libraries, under the usual LLVM license
> - 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
> - coverage profile runtime, asan, tsan, and common runtime libraries separated out from compiler-rt
>
>
> 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).
>
> Thoughts?
>
> 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.
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.
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120531/c3a1ffb1/attachment.html>
More information about the llvm-dev
mailing list