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?


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.

-ben

 
> On Feb 8, 2016, at 12:25 PM, Florian Weimer <fweimer@redhat.com> 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.
> 
> Florian


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