Date: Sat, 01 May 1999 10:51:37 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE> Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/libexec/rtld-elf rtld.c Message-ID: <XFMail.990501105137.jdp@polstra.com> In-Reply-To: <19990430020203.A971@broccoli.no-support.loc>
next in thread | previous in thread | raw e-mail | index | archive | help
Bjoern Fischer wrote:
> On Thu, Apr 29, 1999 at 09:24:10AM -0700, John Polstra wrote:
>>
>> LD_LIBRARY_PATH0
>> RPATH in the shared object
>> LD_LIBRARY_PATH
>> ldconfig hints
>> /usr/lib
>>
>> Would that be acceptable?
>
> This would help the local FreeBSD administrator to override RPATH
> for testing and quick'n'dirty solutions. But it would add a FreeBSD
> specific environment variable.
I have to agree it is just a kludge.
> LD_LIBRARY_PATH is commonly known (and abused). Introducing a new
> environment variable may lead to confusion. There are many traps
> giving a new environment variable the functionality that is commonly
> expected from LD_LIBRARY_PATH.
> What would be harmed if we violate the specification and give
> LD_LIBRARY_PATH precedence over RPATH? I just don't like `Follow
> the specs, no matter whether it's good or bad'.
One justifiable reason to deviate from the spec is if there is
some other factor which causes the rationale behind the spec to be
inapplicable to our situation. And maybe that is indeed the case
here. The spec says the search order should be:
RPATH in the shared object
LD_LIBRARY_PATH
/usr/lib
But the spec took no consideration of the ldconfig hints file. If I
remember correctly, ldconfig didn't even exist in SVR4.0. Maybe the
presence of ldconfig in FreeBSD makes our situation different enough
that the spec doesn't really apply to us. How does this argument
sound? In SVR4, because there was no ldconfig, LD_LIBRARY_PATH was
used in a more system-wide way. It essentially served the same
function that our ldconfig hints serve. Because we have ldconfig in
FreeBSD, it makes sense that LD_LIBRARY_PATH should have a slightly
different role in our system, as a more local or temporary override.
Based on that rationale, our search order should be:
LD_LIBRARY_PATH
RPATH in the shared object
ldconfig hints
/usr/lib
Sheesh, I am starting to sound like a lawyer. :-(
Note, this search order is different from both of the ones I have
tried thus far. Only 21 more permutations to go after this one ... :-)
What do you think? In your opinion (totally unbiased, of course),
does this argument hold water?
John
---
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Self-interest is the aphrodisiac of belief." -- James V. DeLong
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.990501105137.jdp>