[llvm-commits] [PATCH] Shared library for LLVM (issue198059)

[Chris Lattner]

On Feb 17, 2010, at 11:31 AM, Jeffrey Yasskin wrote:

> Ping?

This looks fine to me (though I can't review the lit changes), please name it llvm/tools/llvm-shlib though.  FWIW, I'd rather get this in sooner rather than later in case any issues pop up.  Would it also be possible to get a single test to verify that the library is working?

-Chris

> 
> On Tue, Feb 9, 2010 at 9:58 AM, Jeffrey Yasskin <jyasskin at google.com> wrote:
>> I've fixed the llvm-config problem:
>> http://codereview.appspot.com/download/issue198059_5012.diff
>> 
>> On Fri, Feb 5, 2010 at 2:22 PM,  <jyasskin at gmail.com> wrote:
>>> Reviewers: llvm-commits_cs.uiuc.edu,
>>> 
>>> Message:
>>> We've had requests from packagers in the Unladen Swallow merge PEP that
>>> we link shared against LLVM instead of statically. This patch builds a
>>> libLLVM2.7svn.(so|dylib) and adds an --enable-shared configure flag to
>>> have the tools linked shared. (2.7svn is just $(LLVMVersion) so it'll
>>> change to "2.7" in the release.)
>>> 
>>> On my mac laptop, libLLVM2.7svn.dylib is 39MB, and opt (for example) is
>>> 15M static vs 440K shared.
>>> 
>>> I know of two things that are less than ideal here:
>>> 1) llvm-config gets rebuilt on the second build from an empty objdir.
>>> It's noticing that libLLVM.dylib got created after it did and might have
>>> dependencies. I'm looking into how to fix this.
>>> 2) The library doesn't include any version information. Since we expect
>>> to break the ABI with every release, I don't expect this to be much of a
>>> problem. If we do release a compatible 2.7.1, we may be able to hack its
>>> library to work with binaries compiled against 2.7.0, or we can just ask
>>> them to recompile. I'm hoping to get a real packaging expert to look at
>>> this for the 2.8 release.
>>> 
>>> Current patch at
>>> http://codereview.appspot.com/download/issue198059_3001.diff.
>>> 
>>> Description:
>>> We've had requests from packagers in the Unladen Swallow merge PEP that
>>> we link shared against an LLVM instead of statically. This patch builds
>>> a libLLVM2.7svn.(so|dylib) and adds an --enable-shared configure flag to
>>> have the tools linked shared. (2.7svn is just $(LLVMVersion) so it'll
>>> change to "2.7" in the release.)
>>> 
>>> On my mac laptop, libLLVM2.7svn.dylib is 39MB, and opt (for example) is
>>> 15M static vs 440K shared.
>>> 
>>> I know of two things that are less than ideal here:
>>> 1) llvm-config gets rebuilt on the second build from an empty objdir.
>>> It's noticing that libLLVM.dylib got created after it did and might have
>>> dependencies. I'm looking into how to fix this.
>>> 2) The library doesn't include any version information. Since we expect
>>> to break the ABI with every release, I don't expect this to be much of a
>>> problem. If we do release a compatible 2.7.1, we may be able to hack its
>>> library to work with binaries compiled against 2.7.0, or we can just ask
>>> them to recompile. I'm hoping to get a real packaging expert to look at
>>> this for the 2.8 release.
>>> 
>>> Fixes http://llvm.org/PR3201.
>>> 
>>> Please review this at http://codereview.appspot.com/198059/show
>>> 
>>> Affected files:
>>>   M     Makefile
>>>   M     Makefile.config.in
>>>   M     Makefile.rules
>>>   M     autoconf/configure.ac
>>>   M     configure
>>>   M     test/Makefile
>>>   M     test/Unit/lit.cfg
>>>   M     test/Unit/lit.site.cfg.in
>>>   A     tools/shlib/Makefile
>>>   M     unittests/Makefile.unittest
>>> 
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>> 
>> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits