This is the mail archive of the
mailing list for the glibc project.
Re: A per-user or per-application ld.so.cache?
- From: Ben Woodard <woodard at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 8 Feb 2016 14:51:35 -0800
- 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>
I tried something like that years ago. I wrote them a script which:
1) created a subdir,
2) did a ldd on the specified app,
3) made direct symlinks to all the libraries that it found in the directory that it created.
4) moved the application to the subdir
5) replaced the application with a shell script that pre-pended . (dot) to the library path and then executed the target binary
IIRC the problems with that approach were that that it didnât handle the dlopened binaries and that it didnât fully enumerate the library dependencies.
It was the failure of this approach, that led to the development of spindle.
Cutting down on the directory searching by every compute node would certainly help quite a lot. It still wouldnât solve the problem of getting the data to the thousands of compute nodes but it would tackle the problem with the geometric explosion of directory searching. As I understand it, removing directory searching cuts the time down from several hours to dozens of minutes and spindle brings it down to just a few minutes.
> On Feb 8, 2016, at 12:25 PM, Florian Weimer <firstname.lastname@example.org> wrote:
> On 02/08/2016 09:19 PM, Carlos O'Donell wrote:
>> Why would a long-lived process that uses dlopen fail to benefit from an
>> on-disk cache?
> It's not worth the complexity. (On top of the SUID issue already
> mentioned, there is also the question of cache invalidation.) With
> long-living processes, you could just read in the a designated list of
> directories at startup and use that to seed an ephemeral cache. Hence
> my question about the directory layout.
>> Would you mind expanding on your concern that the solution would not work?
> It would work, it's just more difficult to use.