This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?

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

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.

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.

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

Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]