Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
Jeremy Huntwork wrote: echo CFLAGS += -march=i686 configparms snip Everything went smoothly, so unless anyone has any objections, this is the method I'll be dropping in, except using i486, of course. I won't commit for the next hour or so, however, so that will give at least some time for other comments or objections. One of the downsides of using `-march=' by itself is that it implies `-mtune='. Therefore you have just tuned your libc for i486. Not good. As mentioned previously, GCC-4.2.x tunes for `-mtune=generic' by default. That means, at least for the Ch 6 Glibc, you really should be using these CFLAGS -march=i486 -mtune=generic. I will be adding something similar to DIY soon (but slightly more complicated due to multiple version support). Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
Greg Schafer wrote: One of the downsides of using `-march=' by itself is that it implies `-mtune='. Therefore you have just tuned your libc for i486. Not good. The upgrade to Glibc is in place, which was my only intention for yesterday. Now that it is in place, the community can discuss what it wants to do for -mtune. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
On Fri, 14 Sep 2007 23:16:56 -0400, Jeremy Huntwork [EMAIL PROTECTED] wrote: So, to summarize, I propose not using --with-arch, but use the following for Glibc: CFLAGS=-march=i486 -O2 -pipe ../glibc-2.6.1/configure ...etc. Glibc requires some sort of optimization and -O2 seems safe. -pipe should also be safe on gnu systems and should speed up compile times by using pipes instead of temporary files. Alternatively, we could use CC=gcc -march=i486 ../glibc-2.6.1/configure ...etc. That way, the existing CFLAGS that the Glibc devs have selected will not be overriden. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
On 9/15/07, Jeremy Huntwork [EMAIL PROTECTED] wrote: I suppose it might be possible to introduce the -march flag to CFLAGS without specifying the whole of CFLAGS on the command line... I'll take a look. For LFS, I think it would be better if we just `sed' the -march into the appropriate default. I'd rather avoid the whole '-O2 -pipe' part, even though those are obviously very sane flags. Since I've done squat lately, I'm gonna take a quick look at this. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
On 9/15/07, Dan Nicholson [EMAIL PROTECTED] wrote: On 9/15/07, Jeremy Huntwork [EMAIL PROTECTED] wrote: I suppose it might be possible to introduce the -march flag to CFLAGS without specifying the whole of CFLAGS on the command line... I'll take a look. For LFS, I think it would be better if we just `sed' the -march into the appropriate default. I'd rather avoid the whole '-O2 -pipe' part, even though those are obviously very sane flags. Since I've done squat lately, I'm gonna take a quick look at this. I'm pretty sure that the default CFLAGS are set during the AC_PROG_CC autoconf macro. So, we could either add our own customized macro and rebuild the autotools, or just hack the already generated configure script. This seems to work (I just did a successful build): sed -i.bak 's/CFLAGS=.*-O2/ -march=i486/' configure And now I can see what Greg and Jeremy are talking about where you don't want the -march populating all calls to $CC (as would happen with CC=gcc -march=i486 or by making that the default with --with-arch=i486 to gcc). Glibc seems to have a whole raft of ways it wants to use the compiler. They also have some, uh, creative use of GNU make. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
Dan Nicholson wrote: I'm pretty sure that the default CFLAGS are set during the AC_PROG_CC autoconf macro. So, we could either add our own customized macro and rebuild the autotools, or just hack the already generated configure script. This seems to work (I just did a successful build): sed -i.bak 's/CFLAGS=.*-O2/ -march=i486/' configure Thanks for the research. I can see why you did it this way, because of the way CFLAGS changes through the configure script. We could also do: 's/-O2/ -march=i486/' The difference between that and the one you gave being that this would also hit CXXFLAGS which by default uses the same flags as CFLAGS in the configure script. It doesn't seem necessary to use -march with CXXFLAGS to get glibc to build, but I'm curious as to the result. Is anyone already familiar with Glibc's use of CXXFLAGS? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
Jeremy Huntwork wrote: Thanks for the research. I can see why you did it this way, because of the way CFLAGS changes through the configure script. We could also do: 's/-O2/ -march=i486/' Well I used this sed, except I changed 486 to 686, and everything built successfully. Checking the logs, the Glibc build system doesn't seem to make use of g++ or c++ anywhere, so the change to CXXFLAGS seems harmless. The advantage of the above is that it is shorter, but the advantage to Dan's original is that it is obvious we are adjusting the CFLAGS variable. Of course, that can always be explained in notes, too. Anyone have a preference? I'd like to get Matt's patches and this change into trunk today, if possible. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
This should also work: ./configure... echo CFLAGS += -march=i486 configparms make Instead of an Sed command. The 'configparms' file is lightly documented in the 'INSTALL' file, and is the suggested way to override Makefile parameters. This is a powerfull way to have very fine grained control over the build process, and might be overkill for this purposes. It showcases a neat Glibc feature though. Sorry to complicate this bug-solution even more, but I'd like this forum to get all the available options, to help make the LFS book as correct as possible. robert pgp280VAKuulB.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
Robert Connolly wrote: This should also work: ./configure... echo CFLAGS += -march=i486 configparms make Instead of an Sed command. The 'configparms' file is lightly documented in the 'INSTALL' file, and is the suggested way to override Makefile parameters. This is a powerfull way to have very fine grained control over the build process, and might be overkill for this purposes. It showcases a neat Glibc feature though. Thanks Robert. I actually like this one, because it does just what I'd want it to do, I think. Simply add -march=i486 to the default CFLAGS already present in the build system. I'm getting ready to apply the change to Glibc, I'll hold off for a little bit to allow time for people to comment. And, of course, if we decide to use the above, I'll do a quick test run first. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
On Sat, 15 Sep 2007 16:51:03 -0400, Jeremy Huntwork [EMAIL PROTECTED] wrote: Robert Connolly wrote: Instead of an Sed command. The 'configparms' file is lightly documented in the 'INSTALL' file, and is the suggested way to override Makefile parameters. This is a powerfull way to have very fine grained control over the build process, and might be overkill for this purposes. It showcases a neat Glibc feature though. Thanks Robert. I actually like this one, because it does just what I'd want it to do, I think. Seems a nice approach to me too. I'm getting ready to apply the change to Glibc, I'll hold off for a little bit to allow time for people to comment. And, of course, if we decide to use the above, I'll do a quick test run first. Unsubscribe: See the above information page Thanks Jeremy! Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
The 'configparms' file can exist before or after ./configure is run, in the build directory. I'm not sure which was looks better in the LFS book. robert pgpI6nWm3zIdy.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
Robert Connolly wrote: The 'configparms' file can exist before or after ./configure is run, in the build directory. I'm not sure which was looks better in the LFS book. I just tried this, and I used it before configure, though as you say, it shouldn't make much of a difference since it's processed by the Makefile, not configure. I used: echo CFLAGS += -march=i686 configparms The point being that if it happened that -march=i686 is used incorrectly outside of CFLAGS we know glibc will bomb, not that I thought it very likely that it would. Everything went smoothly, so unless anyone has any objections, this is the method I'll be dropping in, except using i486, of course. I won't commit for the next hour or so, however, so that will give at least some time for other comments or objections. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
Greg Schafer wrote: 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. After doing some tests and a great deal of Googling I've come to agree with Greg's estimation, the above paragraph being part of the clincher. Setting '--with-arch=i486' for GCC results in it using '-march=i486' for *everything*, unless another -march option is specified. As the above example shows, that concept seems contrary to the intention of Glibc developers. I did indeed test building GCC using --with=arch=i686, which would be the same as using CC=gcc -march=i686 for Glibc, and as Greg stated, it causes Glibc to bomb with assembler errors. Conversely, I tested building GCC without using --with-arch and then used 'CFLAGS=-march=i686 -mtune=native -O2 -pipe' ../glibc-2.6.1/configure ...' and built successfully. It seems to prove that it's better to let the Glibc devs decide where to use -march. --with-march=i486 works, but seems prone to breakage. I think if we want to introduce optimization into LFS, then we could do better, and more correctly, than just using --with-arch on GCC. Using CFLAGS with Glibc would allow for other cpu-types for the -march statement and the possiblie introduction of -mtune=native as Greg also suggested. So, to summarize, I propose not using --with-arch, but use the following for Glibc: CFLAGS=-march=i486 -O2 -pipe ../glibc-2.6.1/configure ...etc. Glibc requires some sort of optimization and -O2 seems safe. -pipe should also be safe on gnu systems and should speed up compile times by using pipes instead of temporary files. Anyone have any comments or suggestions? If not, and unless Matt decides to do it first, I'll be applying the patches he created plus the above change to trunk by the end of the weekend. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
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
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
On Thu, 06 Sep 2007 16:09:02 +1000, Greg Schafer [EMAIL PROTECTED] wrote: But getting back on topic, I personally don't buy any of the arguments for using `--with-arch=i486' listed in this ticket: OK, as I also don't want to inflict default optimisation choices on LFSers I can see your point of view, Greg. However, Glibc simply doesn't build on my x86 box without either passing --with-arch=[i386] to GCC's configure command, or setting 'CC=gcc -march=[i386]' before Glibc's configure command. So, for those who aren't well versed in toolchain intricacies (i.e. me), can someone explain what the advantages/disadvantages of each approach are? Thanks. Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: --with-arch=i486 (was Re: Merging the jh branch to trunk)
Matthew Burgess wrote: On Thu, 06 Sep 2007 16:09:02 +1000, Greg Schafer [EMAIL PROTECTED] wrote: But getting back on topic, I personally don't buy any of the arguments for using `--with-arch=i486' listed in this ticket: OK, as I also don't want to inflict default optimisation choices on LFSers I can see your point of view All of Gregs arguments appear to be rational. However, before I again make a decision based on someone else's research, and change the jh branch to something else, I'm going to be digging into this a little further. Although, I probably won't be able to really touch it until tomorrow night. Matt, as far as CFLAGS go, IIRC, glibc must be built with some level of optimization. If you set CFLAGS on the command line, I believe you're overriding what is included by default in the Makefile system, so you must also include some -O option in CFLAGS. -O2 is what Greg uses in DIY. I would think that it would be more ideal to find exactly what it is in the Glibc build system that defaults to i386 and change those defaults with a sed of some sort to be i486. Be warned that I'm just speaking from memory here. As I said above, I will be spending time digging so that I understand the whole system better, but if you get there first, great. Whoever commits this to trunk should understand thoroughly the issue - a mistake I admit I made with the jh branch. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
