Re: shared libraries
On Tue, 7 Dec 2004 22:04:22 +0100, martin f krafft <madduck@debian.org> wrote:
> also sprach Michael K. Edwards <m.k.edwards@gmail.com> [2004.12.07.2147 +0100]:
> > So the server core can load these shared libraries with dlopen(), get
> > the "factory" routines with dlsym(),
>
> With dlopen(), why care about rpath or LD_LIBRARY_PATH? Just give
> the full path or implement your own search path.
The code already specifies the full path to the model being loaded.
But the intention is for symbols referenced by the dynamically loaded
agents to be resolved to the same libraries that are pulled in at
execve() time to satisfy references in the server binary. That
appears to be the way it works now (based on an inspection of
/proc/#/maps). I haven't read up on exactly what effect SONAME and
RPATH in the loaded object have on the behavior of dlopen(); a quick
perusal of the manpage suggests that RPATH in the loaded object has no
effect, but I think I'd better UTSL before relying on that.
The real fun comes in if and when I try to provide multiple versioned
interfaces from the shared libraries so that old builds of shared
agents will continue to work with a newer server core + library set
that provides a revised interface for use by new agent code. Does
anyone have a cookbook for doing this with SONAMEs in C++?
> > In a perfect world, I'd give the libraries reasonably unique names
> > and proper SONAMEs, drop them in /usr/lib, and not need RPATH.
> > But what are the disadvantages to an absolute RPATH (not that
> > ../lib kludge) as long as there are other reasons why the
> > installed path to the binary has to be determined at build time?
>
> I'll leave this up to be answered by some folks who witnessed the
> libc6 migration from the first row.
I hope some of them will weigh in with (a reference to a document
containing) some detail. It sounds like there was a lesson learned
there, and in order for it to stay learned, those of us who missed out
on the fun would benefit from a write-up.
Cheers,
- Michael
Reply to: