This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: A per-user or per-application ld.so.cache?
- From: Siddhesh Poyarekar <sid at reserved-bit dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 9 Feb 2016 00:41:56 +0530
- 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>
On Mon, Feb 08, 2016 at 01:40:05PM -0500, Carlos O'Donell wrote:
> Under what conditions might it make sense to implement
> a per-user ld.so.cache?
>
> At Red Hat we have some customers, particularly in HPC,
> which deploy quite large applications across systems that
> they don't themselves maintain. In this case the given
> application could have thousands of DSOs. When you load
> up such an application the normal search paths apply
> and that's not very optimal.
>
> Might it make sense to have a per-user ld.so.cache for
> this case? Might we even entertain a per-application
> ld.so.cache?
It won't be a bad idea as long as it is ignored when running setuid
binaries.
The other alternative could be extending ld.so.cache to have profiles
for specific binaries in the system path. That is, enhance the format
of files in /etc/ld.so.conf.d/ to have a regular expression (or maybe
even simple wildcards) in the beginning that specifies binaries that
will use these paths first. IIRC we do something similar for hwcaps.
This should also improve performance marginally for applications that
don't need all of those library paths that the files in ld.so.conf.d
add. It will also help maintain a clean namespace in cases where two
installations may have DSOs with the same names but in different
paths.
Siddhesh