[PATCH] Shared library for LLVM

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) 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.
2) llvm-config doesn't yet have an option to print link options for the shared library. I'd like to add this as a subsequent patch.

Fixes http://llvm.org/PR3201.

[nlewycky1, 2010-02-02 17:43:52]

http://codereview.appspot.com/198059/diff/1/4
File tools/shlib/Makefile (right):

http://codereview.appspot.com/198059/diff/1/4#newcode1
tools/shlib/Makefile:1: ##===- tools/lto/Makefile
----------------------------------*- Makefile -*-===##
tools/shlib/Makefile

http://codereview.appspot.com/198059/diff/1/4#newcode1
tools/shlib/Makefile:1: ##===- tools/lto/Makefile
----------------------------------*- Makefile -*-===##
Just FYI, If you want an soname, you'd specify it with -soname 'name' to the
linker. This article is an exhaustive tutorial on the subject:
http://www.ibm.com/developerworks/library/l-shobj/

http://codereview.appspot.com/198059/diff/1/4#newcode60
tools/shlib/Makefile:60: -Wl,-whole_archive
Whoa, that's unexpected. Does it actually drop symbols without this flag? Or is
it just as issue of file ordering on the command line (which shouldn't happen
with llvm-config anyways)?

[Jeffrey Yasskin, 2010-02-05 22:22:59]

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.

[Jeffrey Yasskin (google), 2010-02-09 17:58:26]

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@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@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

[Jeffrey Yasskin (google), 2010-02-17 19:31:14]

Ping?

On Tue, Feb 9, 2010 at 9:58 AM, Jeffrey Yasskin <jyasskin@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@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@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>

[echristo_apple.com, 2010-02-17 19:33:11]

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

> Ping?

Looks reasonable to me. If you can not diff regenerated files next time that
would be helpful :)

Thanks!

-eric

[clattner_apple.com, 2010-02-17 19:38:41]

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@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@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@cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>> 
>> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

[Jeffrey Yasskin (google), 2010-02-18 02:41:57]

On Wed, Feb 17, 2010 at 11:38 AM, Chris Lattner <clattner@apple.com> wrote:
>
> 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?
>

Thanks, I've renamed the directory and changed the examples to link
shared by default. Committed as
http://llvm.org/viewvc/llvm-project?view=rev&revision=96559.

>>
>> On Tue, Feb 9, 2010 at 9:58 AM, Jeffrey Yasskin <jyasskin@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@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@cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>
>>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



-- 
Namasté,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

[Jeffrey Yasskin (google), 2010-02-18 02:42:11]

On Wed, Feb 17, 2010 at 11:33 AM, Eric Christopher <echristo@apple.com> wrote:
>
> On Feb 17, 2010, at 11:31 AM, Jeffrey Yasskin wrote:
>
>> Ping?
>
> Looks reasonable to me. If you can not diff regenerated files next time that
would be helpful :)

Thanks, sorry about that.

> Thanks!
>
> -eric
> _______________________________________________
> llvm-commits mailing list
> llvm-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



-- 
Namasté,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

[nlewycky1, 2010-02-18 21:52:02]

http://codereview.appspot.com/198059/diff/9002/10008
File Makefile.rules (right):

http://codereview.appspot.com/198059/diff/9002/10008#newcode616
Makefile.rules:616: LD.Flags += $(RPATH) -Wl,'$$ORIGIN/../lib'
We should give packagers a flag to tune the rpath path to work around any
problems -- or more importantly, turn it off entirely. The libraries should be
findable through normal ldconfig lookup once installed.

http://codereview.appspot.com/198059/diff/9002/10008#newcode962
Makefile.rules:962: LLVMLibsPaths += $(LibDir)/libLLVM-$(LLVMVersion)$(SHLIBEXT)
I don't follow; examples are linked shared even when shared library is off? Or
is SHLIBEXT the static extension when shared libraries are disabled?

http://codereview.appspot.com/198059/diff/9002/10004
File configure (right):

http://codereview.appspot.com/198059/diff/9002/10004#newcode1406
configure:1406: --enable-shared         Link LLVM tools shared (default is NO)
This sounds independent of whether it builds shared at all. If so, is there a
control for that?

http://codereview.appspot.com/198059/diff/9002/10006
File tools/llvm-shlib/Makefile (right):

http://codereview.appspot.com/198059/diff/9002/10006#newcode64
tools/llvm-shlib/Makefile:64: # at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133.
FYI, gcc prefers 'http://gcc.gnu.org/PR40133' style links. They have switched
bug database software once before.

http://codereview.appspot.com/198059/diff/9002/10007
File unittests/Makefile.unittest (right):

http://codereview.appspot.com/198059/diff/9002/10007#newcode32
unittests/Makefile.unittest:32: Run.Shared :=
$(SHLIBPATH_VAR)="$(LibDir)$${$(SHLIBPATH_VAR):+:}$$$(SHLIBPATH_VAR)"
Oh, it's either this or try modifying the rpath, huh? And if you make the rpath
configurable you're stuck not knowing whether it's relative or absolute. Well,
please add a comment here explaining why you don't just fix up the rpath.

http://codereview.appspot.com/198059/diff/9002/10007#newcode45
unittests/Makefile.unittest:45: $(Run.Shared) $(LLVMUnitTestExe)
The nasty part is that this makes it harder for me to run the unit tests, or to
just run the binary under gdb, etc. Without fixing up rpath, there's nothing you
can do about that.

Then again, you don't really want to install unit tests, and you are very
unlikely to want to run them against the installed libraries... maybe we could
clobber the rpath instead?

[xranby, 2010-02-18 23:23:20]

http://codereview.appspot.com/198059/diff/9002/10006
File tools/llvm-shlib/Makefile (right):

http://codereview.appspot.com/198059/diff/9002/10006#newcode59
tools/llvm-shlib/Makefile:59: ifneq ($(ARCH), ARM)
I tested this workaround on ARM linux using gcc 4.3.3 on ubuntu jaunty
The shared library libLLVM2.7svn.so links +1

But the examples unfortunately fails to link against the shared library:
llvm[1]: Linking Release executable BrainF (without symbols)
/usr/bin/ld: /media/disk/llvm-configure/Release/examples/BrainF: hidden symbol
`__sync_val_compare_and_swap_4' in
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/libgcc.a(linux-atomic.o) is referenced by
DSO

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100215/096473.html

[Jeffrey Yasskin, 2010-02-22 23:48:07]

I think this should fix both arm and darwin8. Xerxes, could you check ARM? I
used -lgcc and avoided linking the problematic unittest against the library
without --enable-shared.

http://codereview.appspot.com/198059/diff/9002/10008
File Makefile.rules (right):

http://codereview.appspot.com/198059/diff/9002/10008#newcode616
Makefile.rules:616: LD.Flags += $(RPATH) -Wl,'$$ORIGIN/../lib'
On 2010/02/18 21:52:02, nlewycky1 wrote:
> We should give packagers a flag to tune the rpath path to work around any
> problems -- or more importantly, turn it off entirely. The libraries should be
> findable through normal ldconfig lookup once installed.

This isn't a regression (the below lines always included an absolute rpath), so
I'll do it in a separate patch, if the packagers need it at all. Note that they
can already patch the Makefile to remove the RPATH; a flag would just make it a
bit easier.

http://codereview.appspot.com/198059/diff/9002/10008#newcode962
Makefile.rules:962: LLVMLibsPaths += $(LibDir)/libLLVM-$(LLVMVersion)$(SHLIBEXT)
On 2010/02/18 21:52:02, nlewycky1 wrote:
> I don't follow; examples are linked shared even when shared library is off?

Yes, per Chris's suggestion. The idea is to test the shared library
unconditionally, but not make the tools do it until it's tested better. However,
not all the examples can link against the .so on arm, so I've enabled particular
ones individually.

http://codereview.appspot.com/198059/diff/9002/10004
File configure (right):

http://codereview.appspot.com/198059/diff/9002/10004#newcode1406
configure:1406: --enable-shared         Link LLVM tools shared (default is NO)
On 2010/02/18 21:52:02, nlewycky1 wrote:
> This sounds independent of whether it builds shared at all. If so, is there a
> control for that?

There's no control for that. Do we need one? What's it hurt to build the shared
library if we don't use it?

http://codereview.appspot.com/198059/diff/9002/10006
File tools/llvm-shlib/Makefile (right):

http://codereview.appspot.com/198059/diff/9002/10006#newcode59
tools/llvm-shlib/Makefile:59: ifneq ($(ARCH), ARM)
On 2010/02/18 23:23:20, xranby wrote:
> I tested this workaround on ARM linux using gcc 4.3.3 on ubuntu jaunty
> The shared library libLLVM2.7svn.so links +1
> 
> But the examples unfortunately fails to link against the shared library:
> llvm[1]: Linking Release executable BrainF (without symbols)
> /usr/bin/ld: /media/disk/llvm-configure/Release/examples/BrainF: hidden symbol
> `__sync_val_compare_and_swap_4' in
> /usr/lib/gcc/arm-linux-gnueabi/4.3.3/libgcc.a(linux-atomic.o) is referenced by
> DSO
> 
>
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100215/096473.html
> 

Darn. I see you tested -lgcc, and it worked better, but not perfectly. I'll try
linking only a specific example against the shared library, so that I can get
this in. Then we can try to get arm shared exception handling working later.

http://codereview.appspot.com/198059/diff/9002/10006#newcode64
tools/llvm-shlib/Makefile:64: # at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133.
On 2010/02/18 21:52:02, nlewycky1 wrote:
> FYI, gcc prefers 'http://gcc.gnu.org/PR40133' style links. They have switched
> bug database software once before.

Done.

http://codereview.appspot.com/198059/diff/9002/10007
File unittests/Makefile.unittest (right):

http://codereview.appspot.com/198059/diff/9002/10007#newcode32
unittests/Makefile.unittest:32: Run.Shared :=
$(SHLIBPATH_VAR)="$(LibDir)$${$(SHLIBPATH_VAR):+:}$$$(SHLIBPATH_VAR)"
On 2010/02/18 21:52:02, nlewycky1 wrote:
> Oh, it's either this or try modifying the rpath, huh? And if you make the
rpath
> configurable you're stuck not knowing whether it's relative or absolute. Well,
> please add a comment here explaining why you don't just fix up the rpath.

I can make the rpath absolute for unittests, but OSX seems to still need the
DYLD_LIBRARY_PATH. It'll help linux anyway.

http://codereview.appspot.com/198059/diff/9002/10007#newcode45
unittests/Makefile.unittest:45: $(Run.Shared) $(LLVMUnitTestExe)
On 2010/02/18 21:52:02, nlewycky1 wrote:
> The nasty part is that this makes it harder for me to run the unit tests, or
to
> just run the binary under gdb, etc. Without fixing up rpath, there's nothing
you
> can do about that.
> 
> Then again, you don't really want to install unit tests, and you are very
> unlikely to want to run them against the installed libraries... maybe we could
> clobber the rpath instead?

Yep, see above.

[xranby, 2010-02-23 09:43:59]

http://codereview.appspot.com/198059/diff/11001/12005
File tools/llvm-shlib/Makefile (right):

http://codereview.appspot.com/198059/diff/11001/12005#newcode61
tools/llvm-shlib/Makefile:61: ifneq ($(ARCH), ARM)
Inverted logic, change this to ifeq ($(ARCH), ARM)

Apart from this minor issue, the patch looks all ok on ARM Linux!