This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Detect obsolete glibcs or kernel headers in libgomp configury (PR libgomp/26175, libgomp/26477)
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 05 Jun 2006 10:04:21 -0700
- Subject: Re: [PATCH] Detect obsolete glibcs or kernel headers in libgomp configury (PR libgomp/26175, libgomp/26477)
- References: <20060605151444.GY3115@devserv.devel.redhat.com>
Jakub Jelinek wrote:
> With this patch we detect prehistoric glibcs or kernel headers in libgomp
> configury and use --disable-linux-futex by default.
Thank you for tackling this!
> If SYS_gettid/SYS_futex isn't defined in <asm/unistd.h>, then libgomp
> wouldn't compile at all, so by default we use --disable-linux-futex
> in that case and for explicit --enable-linux-futex issue an error.
> Otherwise, it checks for compiling against NPTL (then we can pretty
> safely assume it will be run against NPTL too), or, for native builds only,
> if NPTL is used at runtime.
We really don't want to have different behavior for cross and native
configuration. Roughly speaking, every existing case where we do this
in our configuration machinery is a bug. Users should be able to build
cross compilers from any host system to any target system and get a
compiler that behaves identically to one compiled natively.
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?
(650) 331-3385 x713