Default ISA/tuning flags for GCC, --enable-kernel= level for glibc

[Dan Williams]

On Mon, 2009-01-26 at 16:36 +0000, Simo Sorce wrote:
> On Mon, 2009-01-26 at 08:24 -0800, Jesse Keating wrote:
> > On Mon, 2009-01-26 at 07:04 -0800, Ulrich Drepper wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > Jakub Jelinek wrote:
> > > >> The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
> > > >> released kernel seems unlikely.
> > > > 
> > > > I know it is a pain, on the other hand it would really improve Fedora 11.
> > > 
> > > Not only that.  It is the only way to actually test what we are shipping.
> > > 
> > > At least from glibc's POV (but indirectly from a much wider range) we
> > > have to compile everything on the kernel we are shipping for the
> > > release.  Period.  I know that the current build infrastructure doesn't
> > > do this but this only means it has to change.  We have virtualization
> > > available, there is no excuse.
> > 
> > Oh?  And what stable reliable fast software virt do we have for ppc,
> > ppc64, ia64, s390, and s390x?
> > 
> > This is not likely to happen any time soon, so if we want to pick a
> > kernel to run on the builders, it should be the same kernel we pick as
> > the "lowest acceptable kernel" for the variety of targets we build for,
> > which includes RHEL4.  What happens if we pick up the 2.6.29 kernel and
> > try to build RHEL4 packages on it, will they suddenly turn on
> > functionality that can't possibly work on their intended target?
> 
> It might, things like inotify comes to mind ...

Which  means there should be a configure-time option for
--with-fsnotify=[inotify|dnotify] which will turn on the desired method
explicitly.  This stuff certainly shouldn't be autodetected by the
configure script, or if it is, there should be a --with or --enable
method to turn autodetection off and specify.  That's the only way to
ensure that as a package maintainer, you get hard failures at build
time, not when users figure out stuff is broken and yell at you.

Dan

> 
> > I'm with Dan P.B., to obtain specific kernel level functionality it
> > should be possible to override, so that you get a reliable reproducible
> > build result.
> 
> Sure, ideally Dan's arguments are perfectly true, but in practice,
> sometimes, you don't even know where to look for (and by you I mean the
> package maintainer, which is not always necessarily aware of the same
> things upstream is), so the choice I think is:
> - let's pretend we are in the ideal situation and risk shipping some
> broken package
> - let's assume upstream is not perfect so let's try to build on the
> kernel we are going to ship packages with (or a recent enough version
> anyway).
> 
> It is also a problem of testing.
> I, and most other developers build at most on something as old as an
> updated Fedora 9, which has quite a recent kernel. The maintainer may
> not even notice that there are problems when the package is built on
> something as old as 2.6.9
> 
> Simo.
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York
>