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: RFC: Use secondary pthread functions in glibc


On Wed, Sep 12, 2012 at 5:06 PM, Rich Felker <dalias@aerifal.cx> wrote:
> On Wed, Sep 12, 2012 at 11:32:35PM +0000, Joseph S. Myers wrote:
>> On Wed, 12 Sep 2012, H.J. Lu wrote:
>>
>> > The current hjl/secondary binutils branch from
>> >
>> > http://git.kernel.org/?p=linux/kernel/git/hjl/binutils.git;a=summary
>> >
>> > is needed to properly build glibc.
>> >
>> > Any comments?
>>
>> Unless and until you persuade the gABI maintainer that STB_SECONDARY is an
>> appropriate addition to the gABI, using a generic STB_* value there is
>> clearly inappropriate.  There is a real person reading email to
>> registry@sco.com (or was as of a couple of months ago, anyway) and that's
>> who you need to persuade of the merits of STB_SECONDARY.
>>
>> For an OS-specific STB_GNU_* value you'd need to persuade the binutils
>> maintainers of its merits.
>>
>> I have not seen any clear reason why the various suggestions Roland gave,
>> which do not require an ELF extension, would not suffice for any
>> libpthread issues.
>
> I think the issue is that some folks have been trying to push for this
> STB_SECONDARY thing a while, and would prefer to use the current
> pthread breakage with static linking as a wedge to get STB_SECONDARY
> accepted. In any case, I'd rather see libpthread.a fixed and working
> with all reasonably-new versions of binutils rather than requiring an
> upgrade to the latest.
>

Some glibc pthread tests fail when linking statically:

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

You can start working on it from there without using openmp.

-- 
H.J.


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