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

[Simo Sorce]

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 ...

> 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