Re: [PATCH] BZ #5784: Build libpthread.a with ld -r

[Roland McGrath <roland at hack dot frob dot com>]

I really dislike this solution, mostly for the bloat reason.  With an
ET_REL libpthread.a built using -ffunction-sections and linked against
using --gc-sections, the bloat might be avoided while keeping the
simple semantics.  But there isn't any way to make plain -lpthread
turn on --gc-sections, and enabling --gc-sections for the link when
the user didn't ask for it is not really the right semantics.  If the
linker script language grew a way to say:

	INPUT_AND_GC ( ... )

meaning to apply --gc-sections behavior only to unreferenced input
sections coming from the "..." input files, that would be peachy.

In the absence of such an option, I really think we need to examine
the problem more deeply and come up with a different kind of solution.

The STB_GNU_SECONDARY idea seemed hairy and hard to understand, and an
ELF extension is a lousy way to approach a problem for which almost
any other solution can be found, for a variety of reasons.  But I'd
have to examine the proposed STB_GNU_SECONDARY semantics much more
deeply and consider the concrete problems with static linking of
-lpthread in far greater detail to come to a coherent opinion about
that idea.

Anything that requires new linker features has the same problems of
limited and slow possibilities for roll-out.  If we can't find
anything acceptable that doesn't require users to have a linker that
does not yet exist, then something like INPUT_AND_GC seems to me much
easier to get one's head around than STB_GNU_SECONDARY.  (I don't
consider the bloat of this proposal acceptable.)

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.


Thanks,
Roland