Re: shared library from smaller pieces

[Ralf Wildenhues]

Hi Vlad,

* Vlad Skvortsov wrote on Mon, Dec 05, 2005 at 05:34:04AM CET:
> Ralf Wildenhues wrote:
> >* Vlad Skvortsov wrote on Sun, Dec 04, 2005 at 08:01:45AM CET:
> >>
> >>How can I achieve that?
> >
> >You make the other libraries into `convenience archives'.  These are
> >documented in both
*snip*

> Oh, I've overlooked that.. Actually I though that the way objects are 
> packed into particular library is defined in the target library rules 
> and not in dependent ones.

Yep, common misunderstanding.  IMHO, once you get used to the concept,
it can be quite handy.

> >Short: noinst_LTLIBRARIES creates these, they contain objects with PIC
> >code.  You'd do:
> >
> >  noinst_LTLIBRARIES = libaaa.la libbbb.la libccc.la
> >  lib_LTLIBRARIES = libbig.la
> >  libbig_la_LIBADD = ./libaaa.la ./libbbb.la ./libccc.la
> >
> >Now I guess you *also* want to build the program as will, with the stuff
> >linked in statically.  You *can* do
> >
> >  bin_PROGRAMS = foo
> >  foo_LDADD = ./libaaa.la ./libbbb.la ./libccc.la
> >
> >and it will likely work fine, on many platforms.  *However*:  It's not
> >totally portable, it will actually link PIC objects into your program,
> >thus the program will be a bit slower than with non-PIC objects, and
> >of course you should not let foo get anywhere close to libbig, as then
> >you'll have fun with duplicate symbols.
> 
> And what is "the right way" to do it, then?

Either one of these:
- Also create extra static libraries to put in the programs,
   noinst_LIBRARIES = libaaa2.a ..
   foo_LDADD = ./libaaa2.a ...

- Also create static convenience archives to put in the programs
   noinst_LTLIBRARIES = libaaa2.la ...
   libaaa2_la_LDFLAGS = -static
   ...
   foo_LDADD = ./libaaa2.la ...

  I am a bit uncertain about this one, as you likely still need to make
  sure yourself that these archives do not show up in any library you
  also link foo against, to prevent duplicate symbols.

- Fix libtool to create two sets of convenience archives: one with PIC,
  and one with non-PIC objects, and fix it also to allow to put the
  latter one into programs, without the chance of duplicate symbols.

We have the latter on our TODO list.
If I were you, I'd just go with the approach described in my previous
message.


Cheers,
Ralf