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: Merging the jh branch to trunk
On Sat, 15 Sep 2007 01:00:30 -0400, Jeremy Huntwork [EMAIL PROTECTED] wrote: M.Canales.es wrote: Don't should that references be left-out until x86_64 support merge? If it happens to be me that applies these patches this weekend, I'll strip that stuff out, too. Jeremy, would you mind applying the patches some time this weekend please? I'm incredibly busy at the moment, so haven't got time to do anything on the book. If you could also apply the patch that Chris submitted on Wednesday too, that would be great. Then, I think everything's clear for Manuel to apply his patchset. 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)
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: Merging the jh branch to trunk
Matthew Burgess wrote: On Sat, 15 Sep 2007 01:00:30 -0400, Jeremy Huntwork [EMAIL PROTECTED] wrote: M.Canales.es wrote: Don't should that references be left-out until x86_64 support merge? If it happens to be me that applies these patches this weekend, I'll strip that stuff out, too. Jeremy, would you mind applying the patches some time this weekend please? I'm incredibly busy at the moment, so haven't got time to do anything on the book. If you could also apply the patch that Chris submitted on Wednesday too, that would be great. Then, I think everything's clear for Manuel to apply his patchset. Um, yes. :) -- 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 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: Merging the jh branch to trunk
Jeremy Huntwork wrote: Matthew Burgess wrote: On Sat, 15 Sep 2007 01:00:30 -0400, Jeremy Huntwork [EMAIL PROTECTED] wrote: M.Canales.es wrote: Don't should that references be left-out until x86_64 support merge? If it happens to be me that applies these patches this weekend, I'll strip that stuff out, too. Jeremy, would you mind applying the patches some time this weekend please? And that should be all of them. Thanks Matt for making it so easy. Going to sync up the jh branch. Then I need to sort out the bootloader situation with the branch and we can begin considering merging over the x86_64 additions. -- 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: Merging the jh branch to trunk
M.Canales.es wrote: Don't should that references be left-out until x86_64 support merge? If it happens to be me that applies these patches this weekend, I'll strip that stuff out, too. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
El Viernes, 7 de Septiembre de 2007 21:18, Matthew Burgess escribió: Full patch series is now at http://www.linuxfromscratch.org/~matthew/patches/ (see the series file there for the order they need to be applied in). Is there some timeline about when that patches will be applied to trunk? I would prefer to implement the screen attributes addition after that patches has been applied, to not break they and to make more easy the addition merge into the jh branch. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
On Fri, 07 Sep 2007 18:25:54 -0400, Jeremy Huntwork [EMAIL PROTECTED] wrote: Matthew Burgess wrote: Jeremy, did you have to make any changes to the toolchain adjustment phase to cater for GCC-4.2.1? So I'm guessing I avoided what you're hitting now. Here's what is in trunk: gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools@g' \ `dirname $(gcc -print-libgcc-file-name)`/specs And here's what's in the jh branch: gcc -dumpspecs | sed 's@/lib\(64\)\?/ld@/tools@g' \ `dirname $(gcc -print-libgcc-file-name)`/specs Thanks Jeremy, that was exactly the problem. I've uploaded the updated gcc.patch file. I just removed the '^' so the sed only matches what current trunk matches, rather than the ld-uClibc.so.0 entry as well which your '/lib/ld/@' version would. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
El Sábado, 8 de Septiembre de 2007 12:26, Matthew Burgess escribió: Thanks Jeremy, that was exactly the problem. I've uploaded the updated gcc.patch file. I just removed the '^' so the sed only matches what current trunk matches, rather than the ld-uClibc.so.0 entry as well which your '/lib/ld/@' version would. On the gcc.patch file, into the chunk chapter05/gcc-pass2.xml, in the sed and surroinding text that replaces the gcc-specs-patch there is references to linux64.h, /lib64/ld, and /lib32/ld. Don't should that references be left-out until x86_64 support merge? -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
On Wed, 5 Sep 2007 11:12:55 -0600, Matthew Burgess [EMAIL PROTECTED] wrote: On Wed, 5 Sep 2007 17:02:40 + (UTC), Jeremy Huntwork [EMAIL PROTECTED] wrote: Matthew Burgess matthew at linuxfromscratch.org writes: Does this sound sane to everyone? If so, I'll endeavour to complete the patch series as soon as possible and post it here for review. How's this coming? Need any help? Stalled at the minute, thanks to two late nights at work this week! Should be able to get it out for review tomorrow evening. Full patch series is now at http://www.linuxfromscratch.org/~matthew/patches/ (see the series file there for the order they need to be applied in). Unfortunately, this breaks the adjusting phase in chapter 5. If I back out the GCC upgrade it all works fine again, but I don't have time to investigate at the minute. The 032-adjusting jhalfs log is in the same location as the book patches, but I couldn't see anything immediately obvious going wrong! Jeremy, did you have to make any changes to the toolchain adjustment phase to cater for GCC-4.2.1? Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
Matthew Burgess wrote: Jeremy, did you have to make any changes to the toolchain adjustment phase to cater for GCC-4.2.1? I made changes to adjusting.xml for the sake of adding compatibility for x86_64 _before_ I upgraded to gcc 4.2.1. So I'm guessing I avoided what you're hitting now. Here's what is in trunk: gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools@g' \ `dirname $(gcc -print-libgcc-file-name)`/specs And here's what's in the jh branch: gcc -dumpspecs | sed 's@/lib\(64\)\?/ld@/tools@g' \ `dirname $(gcc -print-libgcc-file-name)`/specs Apart from the use of a possible /lib64, the biggest difference is that I don't specify to find the name of the linker at the beginning of a line, because that's not where it appears for x86_64 (and I'm guessing for gcc-4.2.1 on x86 it doesn't appear there either). Can you confirm if the following works? gcc -dumpspecs | sed 's@/lib/ld@/tools@g' \ `dirname $(gcc -print-libgcc-file-name)`/specs I would diff the above with the original output of -dumpspecs to make sure it only hits what you want. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
--with-arch=i486 (was Re: Merging the jh branch to trunk)
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. 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. 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 i486-pc-linux-gnu. 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. 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)
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
Re: Merging the jh branch to trunk
Matthew Burgess matthew at linuxfromscratch.org writes: Does this sound sane to everyone? If so, I'll endeavour to complete the patch series as soon as possible and post it here for review. How's this coming? Need any help? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
On Wed, 5 Sep 2007 17:02:40 + (UTC), Jeremy Huntwork [EMAIL PROTECTED] wrote: Matthew Burgess matthew at linuxfromscratch.org writes: Does this sound sane to everyone? If so, I'll endeavour to complete the patch series as soon as possible and post it here for review. How's this coming? Need any help? Stalled at the minute, thanks to two late nights at work this week! Should be able to get it out for review tomorrow evening. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Merging the jh branch to trunk
Hi guys,
I've been thinking of how best to get the work that Jeremy's done into trunk.
I think what I'd prefer to see is the package upgrades handled separately from
the 64-bit related changes. That way, I'm hoping it'll be clearer what each
change entails. As such, I've started working on a quilt-series of patches
that aim at closing off the package version bump related tickets in Trac, but
are based heavily on Jeremy's work.
For example, to upgrade to Glibc-2.6.1, my patch touches packages.ent,
chapter01/{changelog,whatsnew}.xml as usual. It also touches
chapter0{5,6}/{coreutils,gzip}.xml to fix the futimens issue and
chapter05/gcc-pass2.xml and chapter06/gcc.xml to use --with-arch=i486 so that
Glibc compiles on my x86 box.
My gcc patch would bump the versions, and change the specs patch to the sed,
and add the --disable-bootstrap switch. It wouldn't, however, add the
--disable-multilib or other multi-arch/64-bit features. These would be brought
along in separate commits so they can easily be backed out without having to
revert the version bump as well.
Does this sound sane to everyone? If so, I'll endeavour to complete the patch
series as soon as possible and post it here for review.
Thanks,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
On Fri, Aug 31, 2007 at 11:40:30AM -0600, Matthew Burgess wrote: Does this sound sane to everyone? If so, I'll endeavour to complete the patch series as soon as possible and post it here for review. Yes, that sounds reasonable. Perhaps by the time you're ready to do the x86_64 bits, we can have had the boot loader issues ready for integration. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
On 8/31/07, Matthew Burgess [EMAIL PROTECTED] wrote: Does this sound sane to everyone? If so, I'll endeavour to complete the patch series as soon as possible and post it here for review. Very sane, and I applaud your efforts to keep the diffs nice and clean instead of dropping a patchbomb on trunk. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
On Fri, Aug 31, 2007 at 11:40:30AM -0600, Matthew Burgess wrote: Does this sound sane to everyone? If so, I'll endeavour to complete the patch series as soon as possible and post it here for review. Actually, this is good that you're doing it this way. I just noticed something that I'm surprised I didn't notice before. On the GCC pages the uname test will fail for x86. When I ran tested the build on x86, I did so manually and used slightly different commands, so I never noticed that 'case $(uname -m)' would never match 'x86'. Going to fix that up momentarily. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
Matthew Burgess wrote:
Hi guys,
I've been thinking of how best to get the work that Jeremy's done
into trunk. I think what I'd prefer to see is the package upgrades
handled separately from the 64-bit related changes. That way, I'm
hoping it'll be clearer what each change entails. As such, I've
started working on a quilt-series of patches that aim at closing off
the package version bump related tickets in Trac, but are based
heavily on Jeremy's work.
For example, to upgrade to Glibc-2.6.1, my patch touches
packages.ent, chapter01/{changelog,whatsnew}.xml as usual. It also
touches chapter0{5,6}/{coreutils,gzip}.xml to fix the futimens issue
and chapter05/gcc-pass2.xml and chapter06/gcc.xml to use
--with-arch=i486 so that Glibc compiles on my x86 box.
My gcc patch would bump the versions, and change the specs patch to
the sed, and add the --disable-bootstrap switch. It wouldn't,
however, add the --disable-multilib or other multi-arch/64-bit
features. These would be brought along in separate commits so they
can easily be backed out without having to revert the version bump as
well.
Does this sound sane to everyone? If so, I'll endeavour to complete
the patch series as soon as possible and post it here for review.
That makes sense to me, but I have other issues.
Before the jh branch is merged, there needs to be some textual changes
to describe what we are trying to do. The issues of advantages/
disadvantages of 64-bit vs 32-bit systems needs to be discussed.
Perhaps the best place may be in section 1.2 What's new since the last
release or perhaps earlier.
The section iv. Host System Requirements probably needs to be expanded
too.
I'd like to see the question answered. I have a 64-bit system. How
can I build a 32-bit system?
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.
The M64 variable on the other hand is a gcc compiler option. Why are we
using -m64 for 64 bit architectures? The info page says that is a
deprecated option.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
On Fri, Aug 31, 2007 at 04:54:50PM -0500, Bruce Dubbs wrote: I'd like to see the question answered. I have a 64-bit system. How can I build a 32-bit system? Well, that's an easy answer. Boot a x86 (or 32-bit) kernel and build for x86. The default on the x86 LiveCD works perfectly. 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. The top-level configure doesn't make use of it, but the value is carried over to the sub-configure scripts which do use it. Although, from a cursory examination, it doesn't seem to be used specifically for x86 machines. I'll have to look closer, but I know from experience that it allows Glibc to build whereas it wouldn't before. In any case, yes, there needs to be more description here. I admit I was lazy on that - I was more interested at the time in getting the commands tested. 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. The M64 variable on the other hand is a gcc compiler option. Why are we using -m64 for 64 bit architectures? The info page says that is a deprecated option. Hrm? The man page for gcc 4.2.1 still lists it under 'i386 and x86-64 Options' And then it says: The 64-bit environment sets int to 32 bits and long and pointer to 64 bits and generates code for AMD's x86-64 architecture. Perhaps you were looking under the wrong architecture? Anyway, we use it twice, once for binutils pass 1 and once for gcc pass 1. In each case, the idea is that it forces the compiler to build 64-bit binaries in case it is a multilib system and the default is set to build 32-bit binaries. Since we're currently not supporting the build of a multilib LFS, we want to produce 64-bit only. Once we build a 64-bit ld and a 64-bit gcc, we will by default be producing 64 bit. For most 64-bit hosts, the default is to build 64-bit, so for most cases the use of '-m64' isn't even necessary for those two cases. But it can't hurt to be explicit until we know for sure what we're producing. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
Jeremy Huntwork wrote: On Fri, Aug 31, 2007 at 04:54:50PM -0500, Bruce Dubbs wrote: I'd like to see the question answered. I have a 64-bit system. How can I build a 32-bit system? Well, that's an easy answer. Boot a x86 (or 32-bit) kernel and build for x86. The default on the x86 LiveCD works perfectly. 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. The top-level configure doesn't make use of it, but the value is carried over to the sub-configure scripts which do use it. Although, from a cursory examination, it doesn't seem to be used specifically for x86 machines. I'll have to look closer, but I know from experience that it allows Glibc to build whereas it wouldn't before. In any case, yes, there needs to be more description here. I admit I was lazy on that - I was more interested at the time in getting the commands tested. 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. The M64 variable on the other hand is a gcc compiler option. Why are we using -m64 for 64 bit architectures? The info page says that is a deprecated option. Hrm? The man page for gcc 4.2.1 still lists it under 'i386 and x86-64 Options' And then it says: The 64-bit environment sets int to 32 bits and long and pointer to 64 bits and generates code for AMD's x86-64 architecture. Perhaps you were looking under the wrong architecture? My mistake. It is the -mcpu, -m386, -m486, etc that are deprecated. Anyway, we use it twice, once for binutils pass 1 and once for gcc pass 1. In each case, the idea is that it forces the compiler to build 64-bit binaries in case it is a multilib system and the default is set to build 32-bit binaries. Since we're currently not supporting the build of a multilib LFS, we want to produce 64-bit only. Once we build a 64-bit ld and a 64-bit gcc, we will by default be producing 64 bit. For most 64-bit hosts, the default is to build 64-bit, so for most cases the use of '-m64' isn't even necessary for those two cases. But it can't hurt to be explicit until we know for sure what we're producing. These are generally good answers. My biggest point was to make sure the text is updated in the branch (it doesn't have to be perfect, we can tweak later) before the merge to trunk is made. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
