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


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