Re: Building shared libs as dynamically-loaded perl modules
On Feb 15, 2001, Jeremy Slade <[EMAIL PROTECTED]> wrote:
> As I understand it, a 'convenience' library is intended for two
> things: a static convenience lib is for linking into a program
> (therefore it contains the non-PIC objects, *.o), and a shared convenience
> lib is for linking into another shared lib (therefore it contains the
> PIC objects, *.lo).
Yep. The latter is precisely what you seem to way.
> So I think I want to install the MiscContrib 'convenience lib' to a
> directory where it is accessible for ShapeUtils to link against.
Yep. I think it's time for libtool to start supporting the concept of
installable PIC static libraries. Meanwhile, here's something you can
try: link all the libtool objects that are part of MiscContrib into a
single libtool object file, and install that object file (does libtool
support installing object files? I don't recall for sure). Then,
link that libtool object into your libtool library.
> The same thing applies for linking swigShapeUtils.sl
> against libShapeUtils.a and libShapeUtils.sl.
But this is easier, because they're all in the same package.
> Without libtool, this is all very easy to do -- albeit not easy to do
> in a platform-independent way.
And that's the catch. On some platforms, you just can't link static
libraries into shared ones. Not even if they're PIC. Convenience
libraries, with the abstraction of ``aliases to sets of objects'',
should just work. It's just that they are not currently installable.
I wish they were. And I wish convenience libraries could still come
in PIC and non-PIC versions, just like object files. Currently, every
time you create a convenience archive, you don't get the non-PIC
objects, unless the PIC objects aren't available.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Building shared libs as dynamically-loaded perl modules
Alexandre Oliva writes: > On Feb 14, 2001, Jeremy Slade <[EMAIL PROTECTED]> wrote: > > > It seems that what I really what is to create swigShapeUtils.sl > > using the original ../../lib/*.lo files build earlier (and used to > > create libShapeUtils.sl), rather than create swigShapeUtils.sl with > > a run-time dependency on libShapeUtils.sl (which of course isn't > > installed at the time I'm build swigShapeUtils.sl). In short, I > > think I ultimately want: > > > ld -b -E -o swigShapeUtils.o swigShapeUtils.lo ../../lib/*.lo > > > and not > > > ld -b -E -o swigShapeUtils.o swigShapeUtils.lo -L../../lib -lShapeUtils > > > But how do I achieve that? > > Create ShapeUtils as a libtool convenience library. If you also want > it to be installed as a separate shared library, you can create such a > separate shared library, naming the convenience library differently. > Ditto for MiscContrib. As I understand it, a 'convenience' library is intended for two things: a static convenience lib is for linking into a program (therefore it contains the non-PIC objects, *.o), and a shared convenience lib is for linking into another shared lib (therefore it contains the PIC objects, *.lo). And convenience libraries are not installed, so basically they are only for use during the build process of the package that contains them -- not for linking a program or shared lib in another package. In my case here, I want to create a shared lib, swigShapeUtils.sl, using all the PIC objects from libMiscContrib.la (created in a different package) and from libShapeUtils.la (created earlier in the same package). So I think I want to install the MiscContrib 'convenience lib' to a directory where it is accessible for ShapeUtils to link against. The way things look currently, I can install libMiscContrib.a and libShapeUtils.sl, but not a libtool convenience lib. To build swigShapeUtils.sl, it can't link against libMiscContrib.a since it doesn't have PIC objects, and if it links against libMiscContrib.sl, then it has a run-time dependency on libMiscContrib.sl, which I need to avoid. The same thing applies for linking swigShapeUtils.sl against libShapeUtils.a and libShapeUtils.sl. Without libtool, this is all very easy to do -- albeit not easy to do in a platform-independent way. I would just create and install something like libMiscContrib_PIC.a and libShapeUtils_PIC.a that I could then use to create swigShapeUtils.sl. Why is this so hard with libtool? Or maybe it's not hard and I'm really missing something... Jeremy -- Jeremy Slade Hewlett-Packard Company VLSI Technology Center - http://cpus.hp.com/ [EMAIL PROTECTED](970) 898-7881
Re: Building shared libs as dynamically-loaded perl modules
On Feb 14, 2001, Jeremy Slade <[EMAIL PROTECTED]> wrote:
> It seems that what I really what is to create swigShapeUtils.sl
> using the original ../../lib/*.lo files build earlier (and used to
> create libShapeUtils.sl), rather than create swigShapeUtils.sl with
> a run-time dependency on libShapeUtils.sl (which of course isn't
> installed at the time I'm build swigShapeUtils.sl). In short, I
> think I ultimately want:
> ld -b -E -o swigShapeUtils.o swigShapeUtils.lo ../../lib/*.lo
> and not
> ld -b -E -o swigShapeUtils.o swigShapeUtils.lo -L../../lib -lShapeUtils
> But how do I achieve that?
Create ShapeUtils as a libtool convenience library. If you also want
it to be installed as a separate shared library, you can create such a
separate shared library, naming the convenience library differently.
Ditto for MiscContrib.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Building shared libs as dynamically-loaded perl modules
Tom Tromey writes: > > "Jeremy" == Jeremy Slade <[EMAIL PROTECTED]> writes: > > Jeremy> What I really want to build is 'swigShapeUtils.sl', which > Jeremy> corresponds to the swigShapeUtils.pm module. But automake > Jeremy> complains: > > Jeremy> automake: src/perl/swig/Makefile.am: `swigShapeUtils.la' is not a > Jeremy> standard libtool library name > > Rename it back to what you want and `-module' into > `swigShapeUtils_la_LDFLAGS'. > > This should be documented, but it isn't. I've written a patch for the > manual which I'll check in shortly. Okay, did that, now it's at least happier about the library name... > Jeremy> Anyway, once I make that little change, it builds a shared lib > Jeremy> that doesn't have a bunch of symbols in it, because they are > Jeremy> evidently expected to be in another shared lib at runtime. > Jeremy> These appear to be the symbols that I was hoping to get from > Jeremy> -lShapeUtils (see the LIBADD line above). > > Try putting the -L and -l options into _LDADD and not _LIBADD. First, it complained that I should use _LIBADD and not _LDADD. Not sure if that is significant... So, now I try to build swigShapeUtils.sl, and get the following output during the make process: *** Warning: This library needs some functionality provided by -lShapeUtil. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module swigShapeUtils. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. I don't really understand this whole libtool process yet. It seems that what I really what is to create swigShapeUtils.sl using the original ../../lib/*.lo files build earlier (and used to create libShapeUtils.sl), rather than create swigShapeUtils.sl with a run-time dependency on libShapeUtils.sl (which of course isn't installed at the time I'm build swigShapeUtils.sl). In short, I think I ultimately want: ld -b -E -o swigShapeUtils.o swigShapeUtils.lo ../../lib/*.lo and not ld -b -E -o swigShapeUtils.o swigShapeUtils.lo -L../../lib -lShapeUtils But how do I achieve that? Taking it one step farther: swigShapeUtils also has a dependency on -lMiscContrib, which has been installed at this point. But there again, I would much rather have swigShapeUtils.sl build using the original *.lo that comprise libMiscContrib.sl rather than linking against -lMiscContrib and therefore having that run-time dependency. Any reasonable way to do that? Jeremy btw, here's my current Makefile.am: -- perllib_DATA = swigShapeUtils.pm perllibarch_LTLIBRARIES = swigShapeUtils.la swigShapeUtils_la_SOURCES = swigShapeUtils.C swigShapeUtils_la_LDFLAGS = -module swigShapeUtils_la_LIBADD = \ -L../../lib -lShapeUtil \ -L$(REUSELIB)/lib -lMiscContrib INCLUDES = -I$(PERL_ARCHLIBCORE) -I../../lib -I$(REUSELIB)/include swigShapeUtils.C: ShapeUtils.i $(SWIG) $(SWIG_CXXFLAGS) $(SWIG_NORUNTIME) -dnone -o $@ $^ ShapeUtils.i: Shape.i ShapeRegion.i scaled.i -- -- Jeremy Slade Hewlett-Packard Company VLSI Technology Center - http://cpus.hp.com/ [EMAIL PROTECTED](970) 898-7881
Re: Building shared libs as dynamically-loaded perl modules
> "Jeremy" == Jeremy Slade <[EMAIL PROTECTED]> writes: Jeremy> What I really want to build is 'swigShapeUtils.sl', which Jeremy> corresponds to the swigShapeUtils.pm module. But automake Jeremy> complains: Jeremy> automake: src/perl/swig/Makefile.am: `swigShapeUtils.la' is not a Jeremy> standard libtool library name Rename it back to what you want and `-module' into `swigShapeUtils_la_LDFLAGS'. This should be documented, but it isn't. I've written a patch for the manual which I'll check in shortly. Jeremy> Anyway, once I make that little change, it builds a shared lib Jeremy> that doesn't have a bunch of symbols in it, because they are Jeremy> evidently expected to be in another shared lib at runtime. Jeremy> These appear to be the symbols that I was hoping to get from Jeremy> -lShapeUtils (see the LIBADD line above). Try putting the -L and -l options into _LDADD and not _LIBADD. Feel free to suggest a documentation update which would have made things clearer for you... Tom
