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

[Daniel P. Berrange]

On Mon, Jan 26, 2009 at 10:52:55AM -0500, Simo Sorce wrote:
> On Mon, 2009-01-26 at 09:39 -0600, Mike McGrath wrote:
> > On Mon, 26 Jan 2009, 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.
> > >
> > 
> > Ehh, I assure you if we don't change it... Fedora 11 will still ship so it
> > doesn't "have to change".  So someone needs to articulate, very precisely,
> > what benefit investing time into our buildsystem, testing, release
> > upgrading (Fedora is more expensive then RHEL), etc is going to have.
> > Keep in mind we still can't even build epel on our normal buildsystem yet
> > because of $PEOPLE_TIME
> > 
> > What benefit will it have to our users?
> > 
> > What benefit will it have to our developers?
> 
> Mike, some features in our packages are determined at build time
> depending on what kernel you build them on.

Any case where a build probes for features in the build host's kernel,
or runs just compiled binaries to probe for features, should always also
have  an explicit configure argument (or equivalent) to override the
automatic logic. This is same problem you face with cross-compiling and
places where people left out the 'ACTION-IF-CROSS-COMPILING' arg to the
autoconf AC_TRY_RUN() macro.

> So if the kernel is old enough, you might miss functionality in the
> resulting packages, even more so if that package happens to be glibc I
> think.

If you want to guarentee functionality is built in, then an explicit
configure arg can do this, without requiring that the build host be
running the same kernel version as the eventual target host. This will
give you much more reliably reproducable builds, because you won't find
functionality suddenly turns itself off when rebuilt on a different
system where someone doesn't know about the undocumented requirement
on a particular host kernel version.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|