This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: A per-user or per-application ld.so.cache?
- From: Florian Weimer <fweimer at redhat dot com>
- To: Ben Woodard <woodard at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 8 Mar 2016 11:11:44 +0100
- 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> <6C935651-66F1-411B-AAC7-59B8E4383EC4 at redhat dot com> <56B992AD dot 4010106 at redhat dot com> <B7F74B90-FADB-4CA0-800C-9B7C3FED8C80 at redhat dot com>
On 02/10/2016 12:27 AM, Ben Woodard wrote:
>
>> On Feb 8, 2016, at 11:18 PM, Florian Weimer <fweimer@redhat.com> wrote:
>>
>> On 02/08/2016 11:29 PM, Ben Woodard wrote:
>>
>>> I just talked to one of the developers to get a good sense of the current problem.
>>> The sum of the on-disk file ELF files including debuginfo for one app that we looked at is around 3GB but when we just look at the text in all the ELF files it is 100-200MB depending on architecture spread across about 1400 DSOs.
>>
>> This means that copying the text files together into a single file would
>> be feasible.
>>
>
> Am I understanding you correctly? You’re suggesting linking?
Yes, building a single file which contains multiple DSOs, prior to
shipping to the cluster. This would be just a cache. Unlike static
linking, the presence of an additional library will not cause an
observable difference (beyond use of disk space).
It may be the only way to eliminate the bottleneck.
Florian