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

[David Daney]

Mark Mitchell wrote:
> 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.
> 

How about a configure option to force the desired configuration?

This situation seems similar to not being able to detect runtime TLS 
support in a cross build (see the --enable-tls option).

David Daney