Jordan Brown (Sun) wrote:
> Ali Bahrami wrote:
>> So in your example, the Y that is loaded will depend on whether the
>> application or the shared library X needed it first. Once loaded, the
>> other will use it.
>
> Thanks. I think that answers my immediate question.
>
>> ... However, the most obvious thing to point out is that
>> having multiple 'Y's lying around in the runpath is a dangerous thing
>> to do, and you're asking for trouble down the road, even if you can
>> make it work now. My strong recommendation is to do what you have to
>> do to get down to one 'Y'.
>
> Yeah, I know; I'm not all that happy with it myself.
>
> The problem is that there are a few libraries that our application
> depends on that are available in /usr/lib and /usr/sfw/lib on S10, but
> not on S8 and S9. We want one set of packages to work in both
> environments, and we want to use the system-supplied versions if they
> exist. One idea for a quick fix was to rearrange our RPATH so that we'd
> find them in the system directories if they're there, and fall back to
> the private directory if not.
>
> What I suspect I'll do as a quick fix is to set $LD_LIBRARY_PATH to
> achieve the same effect, since that's process-global and is processed
> before the individual binaries' RPATHs. Longer term, I think we'll yank
> the libraries out of the packages that they're in and only install them
> on systems where we need them. That's more complicated, though, and
> right now complicated is bad.
OK, so you are building a single binary (on S8, it sounds like). There
are some libs on /usr/lib and /usr/sfw/lib on S10 that are not present
on S8/S9, so on those older versions, you must be supplying locally installed
versions (let's say, in /usr/local/lib).
I'm not sensing that you care about version mismatches between
these libraries, so these libs must have stable interfaces, which
is good. Apparently it doesn't matter which one your app gets, as
long as it only gets one of them. Still, you want to give preference
to the Sun supplied versions, if a given system has them.
Is this an accurate synopsis of your question?
It sounds like you should just give all the objects a runpath of
/usr/lib:/usr/sfw/lib:/usr/local/lib
The system libs will get used, if present, because they are at the head
of the list. If not, your private copies will eventually be found.
Or, if your binary and private copies are in a fixed position relative
to each other, an even better idea would be to use $ORIGIN. For example,
if you have a standard subtree with a bin and a lib directory, you might
do something like:
/usr/lib:/usr/sfw/lib:$ORIGIN/../lib
Is there a reason why this wouldn't do what you want on all platforms?
Your original question involved the objects having different rpath orders,
so I suspect that I'm still not understanding some facet of this problem.
Anyway, allow me to point at a recent blog entry about dangers of
LD_LIBRARY_PATH. There is no problem that can't be made worse by
using it, though it is sometimes unavoidable:
http://blogs.sun.com/ali/entry/avoiding_ld_library_path_the
- Ali
