> 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. :-) :-)

I think the main reasons people ask for ld.so.conf is because (a) they are
sick of dealing with LD_LIBRARY_PATH on Sun boxen, (b) nobody has really
promoted the idea of "stamping" executables with the local -rpath preferences,
and (c) most of those people don't want to have to become root to fix things.

-rpath may work great for binaries built locally, but when people build for
/usr/X11R6/lib vs. /usr/X11R6.3/lib or even /usr/lib/X11, downloading those
all onto one system gets unclean pretty fast if you don't "stamp" the binaries
with your local -rpath, or set a global library path with ld.so.conf or
LD_LIBRARY_PATH.

Issue: people who care a lot about stable checksums HATE it when you tweak
their binaries.

I consider the "shared library problem" to be a Stealth Grand Challenge
Problem. It regularly tortures users of Microsoft Windows, and NO ONE has
ever gotten it 100% right on any system I've ever used (unix, mainframe,
micro, or otherwise). Yet no one takes it seriously -- we keep pretending
that if someone COMPETENT would only take charge, that would be the end of it.

What it comes down to is that you have to put up with at least one of:

    1. behavioral bugs due to use of 1 version and fragile interface problems.
    2. duplication of obsolete versions, to AVOID fragile interface problems.
    3. rampant update cycles that take on wavelike properties, to avoid 1 & 2.
    4. diligent rebuilding of all locally used programs, to avoid 1, 2, & 3.

As #4 suggests, if you have responsive root-powered support personnel, a lot
of the practical problems go away. But when you are a Luser who's downloaded
a binary package with the wrong -rpath in it, you are basically shafted if
you don't have an LD_LIBRARY_PATH kludge lever or the ld.so.conf safety net.

> 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.

Now _that_ sounds unequivocally dumb. Why can't it check one first and then
the other? Or am I missing something here.

> 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?

You got that right. One thing I like about the KDE people is that they are
the first group to produce a free GUI for the "click and grunt" crowd. I'm
looking forward to the day when you boot a friend's PC with the NetBSD CD,
pick 'novice installation' and wait... and 20 minutes later the machine
reboots to an xdm login screen with a "me" account (a la NeXT).

Todd Whitesel
toddpw @ best.com