-mtune for Glibc

Bryan Kadzban bryan at kadzban.is-a-geek.net
Fri Oct 5 09:59:18 PDT 2007

On Fri, Oct 05, 2007 at 08:15:09AM -0600, Jeremy Huntwork wrote:
> On Fri, 05 Oct 2007 09:10:59 -0500, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> > Both your links are the same...
> Oh, sorry. Here's the one I left out:
> http://linuxfromscratch.org/pipermail/lfs-dev/2007-September/060268.html

For the record, I agree with Greg's comments in that link (although I
don't do much experimentation with the toolchain, so take that with a
grain of salt).  I'd say that CFLAGS is probably the right place to add
this setting.  (That's just based on Greg's comments about how glibc
doesn't use CFLAGS for .S files.)

As far as -mtune goes, I don't think that having a too-high -mtune value
can cause a bug (even Alexander's conservative settings on the livecd
build use -mtune=i686), so I don't see any problem with adding -mtune to
the book.  I'd also say that "native" is the right value to use, simply
because we don't know exactly what CPU the various users will be
building for.

As for the comments in section 6.1, I'd almost recommend removing -mtune
and leaving it that way.  But that still doesn't quite work well.  Maybe
something like:

Using a non-default optimization level on the toolchain packages
(binutils/gcc/glibc) may cause problems.  The flags used for these
packages in the book have been tested to provide a stable and reasonably
fast system.  Using any other optimization flags for these three packages
is not recommended.

(Or something like that: the points I'm trying to get across are that (1)
the -march flag is required, (2) the -mtune flag doesn't cause any other
grief, and (3) -mtune=i486 would be really slow.  And that we don't do
anything with binutils or gcc because they shouldn't have anything done
to them.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20071005/0ca9b2b6/attachment.sig>

More information about the lfs-dev mailing list