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-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
