This is the mail archive of the
mailing list for the glibc project.
Re: A per-user or per-application ld.so.cache?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Zack Weinberg <zackw at panix dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: Ben Woodard <woodard at redhat dot com>
- Date: Mon, 8 Feb 2016 15:10:08 -0500
- 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> <CAKCAbMgjJdAHGL0PPPmHmvR+ON1vQXUJ=Hs3m2+B1ADWoYtKcQ at mail dot gmail dot com>
On 02/08/2016 02:16 PM, Zack Weinberg wrote:
> On Mon, Feb 8, 2016 at 1:40 PM, Carlos O'Donell <email@example.com> wrote:
>> Under what conditions might it make sense to implement
>> a per-user ld.so.cache?
> My immediate reaction is that ld.so is already too complicated and I
> would hate to see it get even more complicated. Also, I'd like to
> understand why these HPC apps require _thousands_ of DSOs, and what
> their lifecycles are; I'm not convinced we even know what the
> _problem_ is here, let alone the appropriate solution.
Do you really feel ld.so is complicated? My feeling is that it's
poorly documented and poorly tested, but not overly complicated
(though I've been working on dlmopen and other bits so I'm feeling
far more familiar with it than before).
Any changes in this area would need thorough testing, including
building up enough to test ldconfig/ld.so.cache changes from within
a chroot-based testsuite (or something similar).
You can start looking at a problem LLNL has here:
We reference SPINDLE from here also:
The HPC apps don't require _thousands_ of DSOs, it's just the way
they are being developed, Firefox already has 203 DSOs for what is
probably a less complicated application.
We're in touch with various customers and I can relay questions
if we have any, so can Ben Woodard (Red Hat).