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: [PATCH] BZ #5784: Build libpthread.a with ld -r


On Thu, Sep 6, 2012 at 4:15 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Thu, 6 Sep 2012, Roland McGrath wrote:
>
>> Given the severe practical problems of trying to rely on new linker
>> features, I think due diligence requires that we understand very
>> thoroughly the practical problems biting today and look for ways to
>> address them without either depending on new linker features or
>> severely bloating every static -lpthread link.
>
> I think people doing such links today are already using --whole-archive to
> get them to work, so the bloat isn't really new.  Static links generally
> are pretty bloated - the overheads associated with static linking of
> trivial programs are huge - but a baseline where they do at least work
> reliably (where the testsuite failures identified by HJ are fixed, so that
> a --disable-shared build gets clean test results) is probably a better
> basis for reducing the bloat than one with lots of bugs.
>
> That said, I'd certainly be happier if a much more in-depth analysis of
> what the static libpthread issues are - what the cases are where only a
> subset of objects are brought in, and which other objects being missing
> causes problems - were posted to justify any change.  We "know" that such
> links are broken, but don't have a clear self-contained explanation of the
> details to justify the patch.  Maybe linking a smaller subset of objects
> with -r would suffice, for example?
>

I reopened PR 5780 and added my analysis:

http://sourceware.org/bugzilla/show_bug.cgi?id=5780

-- 
H.J.


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