Selective linking of shared libraries.

I am developing an application that uses many executable programs.
Each of these programs needs to be linked with a variable set of object
files and shared libraries. I know how to instruct the linker to select
only those object files that are needed by a program, by putting them
in a library (archive). I wonder whether a similar technique also
exist to instruct the linker to use only those shared objects that
are needed to define unresolved symbols of the program.

As an example:

Suppose I have three library object files A.o, B.o and C.o.
I also have three shared object files X.so, Y.so and Z.so.
Further I have three main programs, compiled to M1.o, M2.o and M3.o.
The main programs need to be linked with a variable mix of these six files,
A.o, B.o, C.o, X.so, Y.so and Z.so.

In the Makefile I do not want to specify for each main program again
which linker options must be used. I want a common set of linker options,
so that a general rule can be defined in the Makefile.

For the .o files, the solution is simple, I put the three of them in a library
(archive) L.a and add this library to the link command and the linker
automatically takes only those modules that are referenced by the main
program.

For the .so commands I do not yet see how this can be accomplished.
It seems that .so files can be put in a library (archive), but the linker
does not use them to satisfy unresolved symbols.
If I add all .so file to the linker command, the resulting executable
requires all .so files at run time, even if it does not use them all.

In earlier times, when I developed applications with the OpenVMS
operating system, I used the concept of "shareable image libraries"
to solve a similar problem.
Is a similar concept also available for Linux?

Thanks,
Fred.Zwarts.
.

Relevant Pages

  • Re: Defining many classes in a single file
    ... And one can declare just as many in a header file. ... Another reason for one class one file is due to linker ... smallest resolution. ... In this case, you can have libraries. ...
    (comp.lang.cpp)
  • FreeBSD 5.1 BETA 2 make cvsup-without-gui fails
    ... checking if the linker is GNU ld... ... checking whether the linker supports shared libraries... ... checking if libtool supports shared libraries... ...
    (freebsd-current)
  • Re: orphaned port?
    ... checking if the linker is GNU ld... ... updating cache .././config.cache ... checking if libtool supports shared libraries... ...
    (freebsd-questions)
  • Re: Problem Fixed
    ... I think you're a bit confused about how the linker works. ... The fileit will look for are somewhat platform specific, ... It looks like your platform uses "libfoo.dylib" for shared libraries. ... the libfoo.dylib "file" is actually a symlink to a versioned shared ...
    (SSH)
  • Re: Coff Object file question
    ... The linker is then handed a bunch of these files. ... Libraries fall into two categories: ... good -- it can then create a final executable file, specifying what ... it specifies the file (e.g. DLL) from which that function is imported. ...
    (alt.lang.asm)