Re: OS-sympathetic installation (fwd)
In message <[EMAIL PROTECTED]>, Alexandre Oliva writes: >it's far easier to just install in a separate directory and have the >package manager collect them. This will work on *most* systems. On >some, it's necessary to have the libraries already installed in the >installation directory before you can correctly link executables or >other libraries dependent on them. This might be solvable by use of chroot. But I can't see a pleasant way to link against libraries which are part of the package as well as against already installed libraries - it seems you'd need to copy or hardlink /usr/lib and friends into the scratch space. Any ideas? Cheers, Olly ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
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 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
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
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Building shared libs as dynamically-loaded perl modules
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> And that's the catch. On some platforms, you just Alexandre> can't link static libraries into shared ones. Not even Alexandre> if they're PIC. Yuck. Alexandre> Convenience libraries, with the Alexandre> abstraction of ``aliases to sets of objects'', should Alexandre> just work. It's just that they are not currently Alexandre> installable. I wish they were. And I wish convenience Alexandre> libraries could still come in PIC and non-PIC versions, Alexandre> just like object files. Currently, every time you Alexandre> create a convenience archive, you don't get the non-PIC Alexandre> objects, unless the PIC objects aren't available. I agree here. I think convenience libraries need to compile two sets of libraries: *.a which contains non-PIC code and *.al which contains PIC code. -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
