Re: [PATCH] Detect obsolete glibcs or kernel headers in libgomp configury (PR libgomp/26175, libgomp/26477)

[Mark Mitchell <mark at codesourcery dot com>]

Jakub Jelinek wrote:

>> I think what you're trying to handle is the case where the user is using
>> the LinuxThreads headers, but has a kernel and GLIBC that support NPTL.
>>   In that case, you want them to use the futex code.  Is that right?  If
>> you're concerned about that case, and unwilling to require that such
>> users add the --enable option themselves, perhaps you could try
>> compiling a program that just makes the futex system call directly?
> 
> The problem is that the sole presence of SYS_gettid/SYS_futex macros in
> the headers doesn't imply the kernel supports that system call and what we
> want to detect in libgomp is whether the kernel will support it.

Well, then, there are two conflicting priorities.

1) Ensure that cross-compilation of GCC behaves the same as native
compilation.

2) Make default behavior as good as possible, requiring a minimum of
user intervention.

I suspect that how one ranks these priorities has a lot to do with how
one uses/builds toolchains.  For example, RHEL toolchains are probably
mostly built natively, and designed to run on the systems on which
they're built.  CodeSourcery toolchains are mostly built as cross compilers.

Probably because of that bias, I'd like to see (1) become an absolute
requirement.  (Right now, it's a guideline, but I don't think we have
consensus that it's a requirement.)  I'd assume some other folks would
say that (1) is an unreasonable restriction.  Oh, well.

> 1) oldest, where kernel wasn't supporting NPTL (nor futex syscall),
>    and only LinuxThreads was installed (so, used for compilation/linking/at runtime)
> 2) kernel NPTL support, LinuxThreads the default for compilation/linking,
>    NPTL default at runtime, unless overridden by env var.
> 3) kernel NPTL support, NPTL used by default for compilation/linking and at
>    runtime, LinuxThreads optionally used for compilation/linking and for
>    compatibility runtime
> 4) no LinuxThreads support, only NPTL

Thanks; very nice taxonomy.

> For 2)/3)/4) we can (and want to, as it is much faster) use futex syscall
> etc. in libgomp.  The patch I posted can detect 3)/4) at compile time
> (for FC that's FC4/FC5) and in that case it can safely assume futex can be
> used.

Good.

> But 2) layout was used for like 3 years in various Linux distros
> and slowing libgomp there by default just because some people still use
> obsolete 1) configurations sounds like a bad idea to me.

Systems with (1) aren't all that obsolete -- NPTL ports for some
architectures are still a work in progress!  (That's especially true for
systems using uClibc, even with full Linux kernels, since uClibc doesn't
support NPTL yet.)

So, the advantage of your approach is that it helps users of systems in
class (2).  The advantage of my approach is that it helps maintain the
cross-build/native-build invariant.

As a possible compromise, I'd certainly be happy to the native-only
check and then issue a warning.  I'm just unhappy about actually
changing the way the compiler is built.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713