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

[jyasskin at gmail.com]

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.

http://codereview.appspot.com/198059/show