Re: A per-user or per-application ld.so.cache?

["Carlos O'Donell" <carlos at redhat dot com>]

On 02/09/2016 01:57 AM, Florian Weimer wrote:
> On 02/08/2016 09:36 PM, Carlos O'Donell wrote:
> 
>> Would you mind expanding on what you would find difficult? Words like better
>> or worse, in a technical context, need explicit descriptions of what is
>> better and what is worse.
> 
> I assume you want to keep a single cache file, right?

I had not considered otherwise, but Mike's suggestion of a LD_LIBRARY_CACHE
which lists multiple files has it's own appeal.

> If I understand the current situation correctly, the system cache is not
> just an optimization, it is also used to effectively extend the search
> path because otherwise, ld.so would not load libraries from
> /usr/lib64/atlas, for example.  (I have a file
> /etc/ld.so.conf.d/atlas-x86_64.conf which lists the directory
> /usr/lib64/atlas.)

Yes.

> I think this means that if you do not update cache, but install new
> system DSO versions, you might no longer be able to find all DSOs.
> Users would need some way to know when to update their caches.

System DSOs are part of /etc/ld.so.cache, and while users might use
their own personal cache to load system DSOs from system directories,
it is not recommended because the user doesn't know when those files
get updated. It's possible, but not recommended, and one should let
/etc/ld.so.cache handle that, and the sysadmin will update that cache 
(or package installs will).

With that out of the way, the user is responsible for caching anything
they have access to change.

> Or we'd have to do that as part of ld.so, but that doesn't seem to be
> particularly attractive because of the limited facilities at that point
> of process life.  This is why I asked if the loading is triggered only
> after user code has run.

Right, it happens very early.

>> The user would have to run 'ldconfig', and perhaps by default we update the
>> user cache and skip updating the global cache if the user lacks the persmissions
>> to do so. Not that different from what we do today with Fedora/RHEL spec files
>> when libraries are installed.
> 
> Yes, and I'm worried that keeping the cache in sync could be too confusing.

Then don't update the cache? Instead make the cache always work.

For example if you had a user/application cache that was relative to $HOME
or $ORIGIN (dynamic string token), then it needs no updates and is relocatable?

If you want to accelerate your application you would use ldconfig to create
a path relative cache file, and then set LD_LIBRARY_CACHE to that cache
file, and when you start your ld.so it loads that cache.

Application developers could ship the cache file with the application and
use a wrapper script to set the env var (like any other required env var
for the application).

This has the added benefit of being able to accelerate RPATH lookups using
the same strategy.

The whole plan certainly needs some more thought.

Cheers,
Carlos.