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 02/08/2016 02:16 PM, Zack Weinberg wrote:
> On Mon, Feb 8, 2016 at 1:40 PM, Carlos O'Donell <carlos@redhat.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:
http://computation.llnl.gov/projects/spindle/spindle-paper.pdf

We reference SPINDLE from here also:
https://sourceware.org/glibc/wiki/Tools%20Interface%20NG

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

Cheers,
Carlos.


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