I need to load multiple versions of a library in the same address
space.

I cannot use dlopen because library dependency is not direct,
and because many parts of code link with this library. For ex., my
application depends on version M of library X, while a third party
library that we link with, depends on version N of library X, where
version M and N are incompatible.

I don't understand symbol versioning fully, but as per my
understanding, they solve this problem and allow us to load multiple
versions of same library in memory.

I am building my library by passing this version script as an argument
to ld, using --version-script option. Using readelf, I am able to find
that the version information is added to the symbol in .dynsym symbol
table [and not in .symtab, unless I link with --export-dynamic].
However, when I link this library with my main program, I see that the
main program does not record its needed version information.

How can I link
my main program so that it records its needed version information, and
makes use of that symbols alone?

Can some one please tell me whether this is the right way to load
multiple versions of same library? Is there any better way?

If this is not the right place to ask this question, kindly point out
the right news group.

If I understand it correctly, each of these module branches maintain
their own symbol table. If the symbols are not available in a module
symbol table, does it load the required libraries? Like libc, stdc++,
etc., If we assume that the library that we are going to load is not
going to depend as much on the libraries that are already loaded,
should we bother about controlling communication?

If I understand it correctly, each of these module branches maintain
their own symbol table. If the symbols are not available in a module
symbol table, does it load the required libraries? Like libc, stdc++,
etc., If we assume that the library that we are going to load is not
going to depend as much on the libraries that are already loaded,
should we bother about controlling communication?

The symbol tables ({DT_HASH, DT_GNU_HASH} + DT_SYMTAB + DT_STRTAB) are
the ones in each module (.so, main).  What turns them into "one" table
is the search order for resolving a reference: which symbol tables are
consulted, and in which order.  Under dlmopen the [basic] search order
is the path to the root along the branch containing the referring module,
except that each node contains a list of modules that were loaded at
the same time by one call to dlopen/dlmopen.

Get the source code to glibc, and consult include/link.h for the internal
definition of struct link_map.  The public definition in <link.h> is only
a small prefix of the real thing.  Note the various "struct r_scope_elem"
which contain lists of struct link_map * to be searched.  Of course
these fields may not be referenced except internally by glibc (they *do*
change from release to release) but understanding their purpose and uses
is reasonably necessary for effective use of dlmopen.

--