--with-arch=i486 (was Re: Merging the jh branch to trunk)
robert at linuxfromscratch.org
Thu Sep 6 00:14:49 PDT 2007
On Thursday September 6 2007 02:09:02 am Greg Schafer wrote:
> 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
> >> --with-arch=pentium4.
> > 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.
You risk Glibc test suite errors if you get crazy with --with-arch, I've tried
it many times.
> 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.
'Because Debian does' it isn't a justification for LFS using it. It was
mentioned so we can expect BLFS packages to have no problems
with --with-arch=i486. As far as I know, no packages will have problems, test
suite failures, or need patches, to support GCC's --with-arch=i486.
> "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.
-mtune (and --with-cpu) won't fix the Glibc problem. I mentioned in the ticket
that I don't think optimization should be used as a justification, in the LFS
book. The issue is getting Glibc to compile, nothing else. Optimization is a
side effect, and if optimization was the only issue then there would be no
> "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
The --with-arch=i486 option is the most transparent option we have for this
bug. CFLAGS will also work to build Glibc. It would be a good idea to present
both options in the LFS book. The advantage I like with --with-arch=i486 is
that it's CFLAGS independent. CFLAGS will override --with-arch=i486 if you
I'm not trying to complicate this discussion, but I personally enjoy using
something like --with-cpu=pentium4 and --with-arch=i486 when building GCC,
and --enable-omitfp when building Glibc, and I don't set CFLAGS. This gives
me modest optimization and lets packages set whatever -O they like without me
resetting it. If the LFS book uses CFLAGS="-march=i486 -O2 -g", and a user
configures with --enable-omitfp, then there's a messy "-O2 -O3" on the same
compile lines. This is why I also suggested using CC="gcc -march=i486" when
building Glibc, instead of --with-arch=i486. The --with-arch=i486 will allow
users to do anything they want with CFLAGS and configure options, and doesn't
conflict with the optimizations or cross-x86 hints. So anyway, I hope this is
> 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.
I never considered how --with-arch=i486 might affect Glibc's .S files. I don't
know anything about the relationship between -march flags and assembly code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the lfs-dev