Re: shared libraries
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
Reply to: