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

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Jun 05, 2006 at 11:02:13AM -0700, Mark Mitchell wrote:
> > This situation seems similar to not being able to detect runtime TLS
> > support in a cross build (see the --enable-tls option).
> 
> Indeed; it's exactly the same situation.
> 
> My concern is the same there; if a cross-compiler does not produce the
> same configuration as a native compiler, then debugging problems on
> non-native systems becomes very difficult.  A common way to debug a
> problem with a native compiler is to build a cross compiler, and if you
> actually get different behavior between the two, then that muddies the
> waters.  It's also common to have both native and cross compilers for
> the same system, using some for on-target builds and some for other
> aspects of development.  Getting different behavior from the two is very
> confusing.

The reason why I'd like to default to --enable-linux-futex as much as
possible is because the two are ABI incompatible (other than that, the
functionality is the same, just the --disable-linux-futex version
is (much) slower).
So, what about:
1) if SYS_gettid/SYS_futex is not in headers, --disable-linux-futex
   (by default) or error at configure time (if user tried
   --enable-linux-futex) - in this case libgomp wouldn't compile otherwise,
   so it is better to compile somehow
2) if it is there, do the compile time check and if building against NPTL,
   default to --enable-linux-futex
3) optionally for native, check for getconf -> LinuxThreads and
   --disable-linux-futex in that case, or e.g. just print a warning
   that it might not work and that the user should consider
   --disable-linux-futex
4) default to --enable-linux-futex
?  We risk some people using not really old kernel headers, but really old
kernels, but that minority shouldn't punish the majority.

	Jakub