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. > > <snip> > > > 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: > > http://wiki.linuxfromscratch.org/lfs/ticket/2018 > > "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 bug here. > "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 > i486-pc-linux-gnu. 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 set -march. 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 worth consideration. > 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. robert
pgpl1H2ePiLzw.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
