Re: Effects of some references to other libraries in a shared library

[Jan Engelhardt]

On Monday 2009-05-04 08:06, John Calcote wrote:
> On 5/3/2009 3:32 PM, Gerald I. Evenden wrote:
>> In a shared library there are about 8 routines out over 100 that refer to
>> libgsl and libpthread.  A frequent situation may arise where an application
>> program has no need for using the 8 procedures infected with other library
>> needs.
>>   [..]
> There are two options: one you mentioned already - separate the 8 routines 
> into
> another library. The other option involves manually loading importing the
> routines you need from pthread and libgsl at run-time. This will clear the 
> hard
> dependency on these other libraries. And if you call these 8 routines only 2
> percent of the time, then it will also clear soft dependencies for your users
> 98 percent of the time.

(a) using libtool to create libfoo.la, then libfoo's dependencies
("-lgsl -lpthread") should be recorded in the .la file and

  1. if libfoo.so is built, then libfoo.so will have -lgsl -lpthread
  dynamically linked (on ELF where supported); cf. `ldd libfoo.so`.
  Your program will only need program_LDADD = -lfoo, not gsl nor pthread
  (unless the program uses them directly, without the indirection of libfoo)

  2. if libfoo.a is built and used, then appropriate/required .o files
  from the archive will be linked into the program. libtool --mode=link
  (all behind automake doors) will also pass -lgsl and -lpthread to
  ld -o program, resulting in either a shared library reference to
  gsl/pthread or .o's from the .a's where necessary.
  "Where necessary": If libfoo_invoke_gsl is never called from program,
  and invoke_gsl is in its own .o file, ld won't link in the .o and
  hence would not need to add libgsl.
  
(b) without libtool: since noone records the dependencies like an
.la file would, you have to remember said list and add it to
program_LDADD manually. Other than that, behaves as a.2.

You see,it all happens automatique (almost), and does the right thing
give the developer gave care to have seperate .os produced for a
potential .a.