[ntp:hackers] pthread_once under linux

juergen perlinger juergen.perlinger at t-online.de
Fri Sep 25 07:49:01 UTC 2015


On 09/25/2015 03:33 AM, Harlan Stenn wrote:
> juergen perlinger writes:
>> On 09/21/2015 06:13 AM, Harlan Stenn wrote:
>>> Harlan Stenn writes:
>>>> I might have found the problem.
>>>
>>> ... and the fix for bug 2332 seems to be the cause.
>>>
>> How? As far as I can see, linking statically/forced against libgcc_s
>> should not pose a problem. Especially *not* at link time!
> 
> This has been a mystery for me for a while.  All I can say is that when
> I remove the link for libgcc_s from these test programs, the problem is
> solved.
> 
> When I then provide -pthread (on some systems, various other
> incantations on other systems) the original programs build fine
> everywhere I have tested, and run fine on the few places I've been able
> to test.
> 
>> OTOH, why is this used at all for the test programs? This kludge is only
>> needed when a daemon drops its privileges and then wants to use some
>> thread functions, to name one, pthread_cancel(). And then so far only
>> under Linux with some versions of the C and pthreads library.
> 
> Yes,  I haven't been able to get to the bottom of this one either.
> 
>> Why are the test programs not just compiled/linked with a simple
>> '-pthread'? Isn't that the GCC standard way to get all the pthread stuff
>> that's needed on board?
> 
> Because:
> 
> - we don't always use gcc
> - as we put more tests into the build and we run 'make check' or
>   or distcheck on more platforms, local issues with the test suite
>   stop the build.  I just fixed a problem with the priority queue stuff
>   last night.  I'm digging in to 2+ more problems on various machines
>   in our test farm at the moment, too
> 
> The above are the short answers.  The longer answers involve "having a
> robust test suite is a good thing, and the problem is that with pthreads
> and the extra education I'm getting with memlock and rlimit and mcast
> and ... it will be Really Swell if we can "raise the bar" and have a
> useful test suite.

Preaching to the convicted ;) Yes, '-pthread' is compiler specific -- I
guess CLANG and GCC need it, other compilers might/will do it different.

I probably should have made clear that I wanted '-pthread only applied
to compilers that support it. Ideally the pthread autoconf suite should
find that out, but I know it's not *that* simple.

There's also a runtime solution to this problem, not a nice one, but doable:

In the daemon (and only there) we do check if the OS is a Linux and
'dlopen()' is available; if so, we simply try load to libgcc_s, ignoring
the result. This must be done early, before the user privileges are dropped.

This should IMHO solve the problem in a way that keeps the ugliness
localised to the daemon while not affecting the link/build of other apps.

Any votes on going that way?

> 
> Oh, I'm getting quite an education in pthreads and autoconf macros, too.

I believe  that. I tried to wrap my brain around autoconf suites for
pthreads once with a slight headache as the only result. The topic was
not urgent at the time so I did not keep up... Seems I should have spent
more time on it.

Cheers,
	Pearly


More information about the hackers mailing list