> From port-alpha-owner-ross=teraflop.com@NetBSD.ORG Tue Jul 21 07:57:12 1998
> To: salvet@ics.muni.cz
> Cc: port-alpha@NetBSD.ORG, tech-userlevel@NetBSD.ORG
> Subject: Re: Shared object "libX11.so.6" not found
> From: Havard.Eidnes@runit.sintef.no
> Date: Tue, 21 Jul 1998 16:56:29 +0200
> X-MIME-Autoconverted: from quoted-printable to 8bit by random.teraflop.com id HAA06922
>
> > I think it would be better to enhance the ELD ld.so so that it
> > could consult /var/run/ld.so.hints (like a.out ports do) unless
> > -R/-rpath is specified. Then one can move libraries without
> > relinking apps.
>
> Hm, not sure I agree to the solution, although I can sympatize
> with the desire for flexibility.
>
> There are existance proofs that other ELF systems can make do
> without a cache.  Someone else told me earlier that HP-UX has a tool
> (ld in HP-UX case, if I remember correctly) which can re-target the
> compiled-in -rpath directives, and that seems to me to be the right
> way to deal with this problem.  It has also been pointed out to me
> that RedHat Linux has an ELF system which *does* use a cache
> constructed with ldconfig.  Some say that approach is horribly
> wrong...
>
> - Håvard
>


Interesting points. This subject comes up periodically when people haven't
set the -rpath _at all_, and then want the ld.so.conf and they advance the
obvious it-should-be-configurable argument.

I would have a lot more sympathy for the ld.so.conf argument if it wasn't
advanced so frequently in response to someone not even using the existing
mechanism at all. If you want to make up in /etc for lossage elsewhere
then _please_ admit it, don't make a configuration argument when you are
really saying you don't want to fix the library builds. :-) :-)

Having said that, I did write and distribute some code six months ago to
add an ld.so.conf to the elf dynamic loader, so it's now at the level of
a policy decision.  I have my doubts about whether this code should be
used, however.

One big problem with the ld.so.conf approach is that it doesn't mix at all
well with -rpath, so by using ld.so.conf, you have to give up -rpath. It's
a one-way road, not just an optional feature. And remember...the end result
of endless configuration knobs is stuff like .fvwm2rc; I think it's really
cool but what chance does joe random user have of setting it up? And how
do you document a system where nothing is known and anything could be
changed?

Ross
-------------------------------------------
NetBSD CD's available now at www.netbsd.com