On Tue, 7 Dec 2004 22:04:22 +0100, martin f krafft <[EMAIL PROTECTED]> wrote: > also sprach Michael K. Edwards <[EMAIL PROTECTED]> [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
