-mtune for Glibc

Bruce Dubbs bruce.dubbs at gmail.com
Fri Oct 5 11:16:53 PDT 2007


Dan Nicholson wrote:
> On 10/5/07, Dan Nicholson <dbn.lists at gmail.com> wrote:
>> I think adding -mtune=native will be fine so long as there are no test
>> regressions. Otherwise, Greg's suggestion of -mtune=generic seems very
>> safe.
> 
> Reading Greg's post again, if -mtune=generic is the default on
> gcc-4.2, then I think that's what we should restore. Then the
> explanation makes more sense: "-mtune=generic restores the default GCC
> settings from those implied by the -march parameter." Eh, that stills
> sounds like gibberish.

OK.  In 5.6. Glibc-2.6.1 of SVN-JH-20071004 we have:

Because Glibc no longer supports i386, its developers say to use the
compiler flag -march=i486 when building it for x86 machines. There are
several ways to accomplish that, but testing shows that the flag is best
placed inside the build variable “CFLAGS”. Instead of overriding
completely what Glibc's internal build system uses for CFLAGS, append
the new flag to the existing contents of CFLAGS by making use of the
special file configparms:

Lets change the last sentence to:

Instead of overriding completely what Glibc's internal build system uses
for CFLAGS, append the new flag to the existing contents of CFLAGS by
making use of the special file configparms.  The -mtune=native flag is
also necessary to reset a reasonable value value for -mtune that is
changed when setting -march.

if [ uname -m | grep -q i[4-7]86 ]; do
  echo "CFLAGS += -march=i486 -mtune=native " > configparms
done

Note that I changed the && to an if to make it more obvious that the
grep is a test.  IMO, the && would be OK if we could get the entire
s1 && s1 on one line, but the text (after adding -mtune) is too long.
-----------
In 6.1. Introduction, change:

Also note that the -march and -mtune options may cause problems with the
toolchain packages (Binutils, GCC and Glibc).

to

Also note that changing the -march and -mtune options using values not
specified in the book have not been tested. This may cause problems with
the toolchain packages (Binutils, GCC and Glibc).
------------
In section  6.9.1. Installation of Glibc, the CLFAGS structure would
also need to be changed to match the changes in section 5.6.

  -- Bruce




More information about the lfs-dev mailing list