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

[jyasskin at gmail.com]

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