--with-arch=i486 (was Re: Merging the jh branch to trunk)
gschafer at zip.com.au
Wed Sep 5 23:09:02 PDT 2007
Jeremy Huntwork wrote:
> On Fri, Aug 31, 2007 at 04:54:50PM -0500, Bruce Dubbs wrote:
>> There also needs to be more explanation in the text interspersed with
>> the instructions. For instance in "5.4. GCC-4.2.1 - Pass 1" we have:
>> "Also, the --with-arch flag is only necessary for x86 machines."
>> The WITHARCH variable seems to be a configure option, but I can't find
>> it in ./configure --help or with a grep of configure. In any case, I
>> have Pentium 4 CPU. Why do I want to use --with-arch=i486 instead of
> As Greg mentioned, by using --with-arch, we are
> effectively introducing optimization into the build. Much text in the
> book needs to be adjusted to show why we are using this and what is
> considered 'safe'. Also, AFAIK, you could conceivably use pentium4, or
> whatever fits your CPU - again, it's optimization.
I want to go on record as saying `--with-arch=i486' is wrong for LFS.
Note: I'm not against optimization in general. In fact, just the opposite.
After all, if you're going to the trouble of building your own Linux
system (and you are experienced) then you are in the perfect position to
take advantage of any safe optimizations that are available. But having
said that, LFS wisely does the right thing by not promoting optimization
to its target audience.
But getting back on topic, I personally don't buy any of the arguments for
using `--with-arch=i486' listed in this ticket:
"coz Debian does it" - this change is being proposed because of Glibc, and
we all know defacto upstream Glibc is Red Hat/Fedora, and they do NOT do
it this way. They use CFLAGS which is the proper Glibc way. See below.
"you can't copy code to real i386 anyway, so why lose by default" - bogus
argument. This kind of thing comes up on Fedora lists all the time. The
expert's opinion is that `-mtune=' provides far more benefit than any
`-march=' flag which is why they actually use `--with-cpu=' for gcc.
"it's a binary compatibility issue" - bogus argument. The meaning of "ABI"
is well defined. Please show any real life example of where mixing
different -march= compiled x86 code makes a difference. It doesn't.
I also don't buy the "entire system is built consistently" comments from
the commit. The whole toolchain is actually an i686-pc-linux-gnu
configured toolchain. I'm sorry, but that ain't consistent with i486. At
least Debian *are* consistent because they configure their toolchain as
But the worst part IMHO has already been pinpointed by Bruce in that it
will encourage novice users to play with `--with-arch=my-uber-cool-cpu'.
This isn't bad in itself but it can lead to problems. For example, it has
been well known for years that you cannot compile Glibc with a GCC that
was configured as `--with-arch=i686' (unless you patch Glibc). It bombs
out due to conflicts in GCC preprocessor macros with Glibc assembler code.
This is arguably a bug in Glibc, but the fact that Glibc devs refuse to
fix it indicates rather strongly that CFLAGS is the correct way to build
Glibc. It also proves that CC="gcc -march=i?86" is wrong for Glibc. To
clarify, if you give CFLAGS to Glibc configure, it will build .c files
with those flags but it won't use them for .S files.
In summary, it is MHO that configuring Glibc with CFLAGS="-march=xxx etc"
is the more technically correct way and less likely to encourage novice
users to hose their system.
BTW, on a side note. As is already well known GCC-4.2.x enables some
interesting new options, namely `generic' and `native' ie: you can pass
`-mtune=native' and gcc will automatically tune for your k8 if you happen
to be running Athlon64 etc. `-mtune=generic' is now the default. ie: the
defaults on i686-pc-linux-gnu have now changed like this:
gcc-4.1.x -march=i386 -mtune=i686
gcc-4.2.x -march=i386 -mtune=generic
However, the GCC docs say this about generic:
"Produce code optimized for the most common IA32/AMD64/EM64T processors.
If you know the CPU on which your code will run, then you should use the
corresponding -mtune option instead of -mtune=generic. But, if you do not
know exactly what CPU users of your application will have, then you should
use this option."
Obviously, -mtune=generic is ideal for distros. But IMHO (and according to
the above) -mtune=native is probably better suited for us folks. The
upshot of all this is - if using GCC-4.2.x and including a `-march=' flag
in the CFLAGS given to Glibc configure, it's probably best to also give an
`-mtune=' flag, either "generic" or "native".
More information about the lfs-dev