llvm dev - Jun 2008 - [LLVMdev] Shared libs?

I've been playing with LLVM for a couple of months now and really am  
enjoying myself. I finally got around to doing something useful and  
had started implementing bindings for Ruby. I've been working off the  
tip of trunk and realized my build didn't have shared libs. I've spent  
the better part of a day trying to build llvm with shared libraries  
with no luck on either Mac OS X 10.5.2 , or Ubuntu 8.04.

Exactly what magic incantation must I pass to configure?

I've tried:

--enable-shared
--enable-shared=yes
--enable-shared=core, --enable-shared=Core, --enable-shared=all

and all of the above with various flags such as:

--enable-pic
--disable-static

And still not a single shared lib in sight. The only other flags I am  
using are "--enable-targets=host-only" and
"--enable-optimized."

Tomy

On Sun, Jun 8, 2008 at 7:57 PM, Thomas Hudson <hudson at speakeasy.net>
wrote:
> I've been playing with LLVM for a couple of months now and really am
> enjoying myself. I finally got around to doing something useful and
> had started implementing bindings for Ruby. I've been working off the
> tip of trunk and realized my build didn't have shared libs. I've
spent
> the better part of a day trying to build llvm with shared libraries
> with no luck on either Mac OS X 10.5.2 , or Ubuntu 8.04.
This isn't first-hand, but from what I remember hearing on IRC,
putting llvm into shared libraries caused a ridiculous explosion in
dynamic linking (and therefore startup) times.  So there is no option
to make shared libraries, at least at the moment.

If you'd like to elaborate on why exactly you need shared libs, you
might get a better answer.

-Eli

Eli Friedman wrote:
> This isn't first-hand, but from what I remember hearing on IRC,
> putting llvm into shared libraries caused a ridiculous explosion in
> dynamic linking (and therefore startup) times.  So there is no option
> to make shared libraries, at least at the moment.
Well, by tweaking configure and make options, I've managed to build LLVM
2.2 shared libraries on Linux (x86), and they seemed to work fine. (I
did have to work around a circular dependencies error, though.)

This makes a *lot* of sense. E.g., my application is a functional
language interpreter (http://pure-lang.sf.net) which has to be linked
against most of LLVM, and it makes a whole lot of a difference to have
those 8+MB of libraries being handled by the dynamic linker instead of
including them all in a fat interpreter executable, for the same reason
that you don't want each and every C/C++ application to link libc and
the C++ library statically. Just imagine that you have 50 instances of
the interpreter running simultaneously!

Note that you can also work around this by just linking the static LLVM
libs into a shared lib which in turn is linked against your application.
That's what I actually do with my interpreter now, since the users
shouldn't have to tweak the LLVM stuff just to build my interpreter.
(Unfortunately, that approach doesn't work on x86-64 with LLVM 2.2,
since some parts of the LLVM JIT apparently contain non-relocatable
code; I hope that this will be fixed in the forthcoming LLVM 2.3.)

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag

On Jun 8, 2008, at 9:36 PM, Eli Friedman wrote:
>
> If you'd like to elaborate on why exactly you need shared libs, you
> might get a better answer.
>
Because I'm writing an extension to a scripting language interpreter.  
Perl/Python/Ruby all need to be able to dynamically load the library  
when the user 'requires' or 'imports' the extension.

Obviously I can write a C wrapper which references LLVM and links it  
as a shared object. But it might be nice to issue a warning when  
someone uses the "--enable-shared" flag, or perhaps remove it if it is
not supported. Or at least put something on the web site that Google  
would find. :-)

Tomy

Hello, Cyrille
> Unfortunately it's not fixed in 2.3 :( I made a patch ([1]) for 2.2 and
gave
> it to one of the developer, I guess he forgot about it
No, I don't forget about it. 

The problem is that stuff for x86-64 seems to be really easier, than for
x86-32 (RIP-relative PIC vs GOT-relative, also we should think about
darwin). I thought to add x86-32 support there as well, but I was really
lack of free time, sorry.

-- 
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.