This is the mail archive of the
mailing list for the glibc project.
Re: A per-user or per-application ld.so.cache?
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: libc-alpha at sourceware dot org, Ben Woodard <woodard at redhat dot com>
- Date: Tue, 9 Feb 2016 07:57:31 +0100
- Subject: Re: A per-user or per-application ld.so.cache?
- Authentication-results: sourceware.org; auth=none
- References: <56B8E105 dot 8030906 at redhat dot com> <56B8E810 dot 1040609 at redhat dot com> <56B8F860 dot 6060707 at redhat dot com> <56B8F9CC dot 4080205 at redhat dot com> <56B8FC41 dot 7040107 at redhat dot com>
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
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.