[Gllug] libs, but where?

[Nix]

On Fri, 26 Jul 2002, tet at accucard.com uttered the following:
> 
>>I cannot see how you can *possibly* say that an option that forbids
>>moving shared libraries around without relinking all binaries linked
>>against them is preferable to one that allows moving of shared libraries
>>at any time with no more difficulty than changing one path in one file
>>and running /sbin/ldconfig.
> 
> The main problem with your argument is that it assumes you a) have
> root access when installing software,

No, it gives you a better option than DT_RPATH when installing as root.

Of course the other (worse) options are available at other times.

I have a ~50%-complete patch allowing per-user ld.so.confs and
ld.so.caches; I really should finish it off and submit it. (Right
now it's fairly inflexible; the cache and config file have to be
in ~/etc/, which rules out the use of the patch for users without
home directories.)

>                                       and b) that the software will
> only be used locally. Most of my software is installed in a shared NFS
> environment, where it's certainly not feasible to modify each client
> to look for libraries in the correct place. Sure, I *could* manully go

Whyever not? Have a scheme that does a nightly find(1) over your shared
tree and grabs the directories containing all shared libraries (that you
want to use: obviously your criteria here can be arbitrarily complex)
and composes an ld.so.conf from them.

Or paste the ld.so.conf together from bits rsynced to each machine.

Or something else.

> my main problem with ld.so.conf is that it seems designed with a
> single standalong machine mentality, which is the complete opposite of

Is this because it has to be in /etc?

That constraint is reasonable given the side-effects that libraries in
/etc/ld.so.cache have got (e.g. they are searched even for suid
binaries). My patch will (this being the bit I haven't written yet and
the reason I haven't released it) search ~/etc/ld.so.cache before
/etc/ld.so.cache, but only for non-suid binaries.

(Hm. I wonder whether I should have an LD_SO_CONF_PATH? It'd not be as
inefficient as it seems because it'd be searched by ldconfig *only*,
and ld.so.cache would reference all libraries from all paths in all
the ld.so.confs... but probably this is a feature too far. ;} )

> what I primarily use Unix for (i.e., environments where I typically
> install stuff for use by many people on many machines).

I'd say an ld.so.conf-fragment-rsync-and-assemble-nightly-from-cron
scheme would be nearly ideal there. (I'd not recommend sucking the
fragments in over NFS though given NFS's charming security
features. ;} )

> But then I guess neither of us represent the typical end user
> demographic...

I'll say not :)

-- 
`There's something satisfying about killing JWZ over and over again.'
                                        -- 1i, personal communication

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug