I wrote: > ... 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.
Note that I haven't verified whether RPATH in the loaded object has an effect on dlopen(), but it clearly does have an effect on the use of "ldd -r" to inspect the resolution of its symbol references. That's actually a downside to putting the shared libraries (private to this application) in /usr/lib; it makes it harder to automate the build-time check that everything resolves correctly against the library versions we just built. "LD_LIBRARY_PATH=/path/within/build/tree ldd -r foo.model" should still get the newly built copies instead of the ones in /usr/lib, but one would want to inspect its output to make sure. (Imagine that a library has been removed or renamed in the new build, but the old name is still included in the link step for some agents; if an old build is installed on the machine, then "ldd -r" will report a "false success" during smoke testing.) For this purpose, it would be preferable for the installed location of these libraries to be (say) /opt/whatever/lib, and for this path to be in the server binary's RPATH, but for the model shared objects' RPATH to be empty. Then the models can be reliably smoke tested against the libraries in the build tree (and, using other LD_LIBRARY_PATH values, against other library sets from previous builds), but loading them using dlopen() will use the same RPATH used to resolve symbols in the server binary. Right? I'm not saying there aren't other arguments against RPATH. Just isolating a use case for which RPATH is the best solution I know of. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
