This is the mail archive of the
mailing list for the glibc project.
Re: Improve consistency of --enable-kernel and default builds
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 14 May 2012 12:00:24 -0400
- Subject: Re: Improve consistency of --enable-kernel and default builds
- References: <Pine.LNX.email@example.com>
On Mon, May 14, 2012 at 11:40 AM, Joseph S. Myers
> If the user passes --enable-kernel, that version (or the
> architecture-specific minimum, if the --enable-kernel version was too
> old) is always used to set __LINUX_KERNEL_VERSION and
> __ABI_TAG_VERSION. ?If the user does not, those are set only if the
> architecture's minimum is greater than the global minimum (currently
> 2.2.0). ?This works as long as patches removing old kernel support do
> what my pre-2.2-removal patch did and remove every conditional on the
> old kernel version; it doesn't allow multi-stage removal of support
> for old kernel versions (first increase the default, then gradually
> remove the conditionals).
> I propose this patch to make things simpler and more consistent by
> always setting minimum_kernel (and so those two macros, and so causing
> the ABI tags always to give the configured minimum kernel whether or
> not it's the global minimum). ?Tested x86.
> 2012-05-14 ?Joseph Myers ?<firstname.lastname@example.org>
> ? ? ? ?* sysdeps/unix/sysv/linux/configure.in (minimum_kernel): Always
> ? ? ? ?set if not set by the user. ?Do not allow for being unset.
> ? ? ? ?* sysdeps/unix/sysv/linux/configure: Regenerated.
I'm OK with this.
This looks like a step in the right direction.
The less variance there is in the build process the better.