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.
