Re: LFS 6.3 stealth update complete
El Jueves, 30 de Agosto de 2007 06:33, Bruce Dubbs escribió: I updated all the 6.3 files on the server so the md5sums in the book now match the md5sums of the files. No filenames were changed. Great, now all packages are downloaded without issues :-) Many thanks. -- 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: LFS 6.3 stealth update complete
On 8/30/07, M.Canales.es [EMAIL PROTECTED] wrote: El Jueves, 30 de Agosto de 2007 06:33, Bruce Dubbs escribió: I updated all the 6.3 files on the server so the md5sums in the book now match the md5sums of the files. No filenames were changed. Great, now all packages are downloaded without issues :-) Phew! I was hoping all the issues had been fixed. Thanks everyone (especially Bruce) for getting everything put together. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Summary: Debian Lenny as host
Hello, Here's the build status of the jh branch: Debian Lenny for x86: Success Debian Lenny for amd64 (multilib with 64-bit userspace): Success Debian Lenny for amd64 (multilib with 32-bit userspace installed with debootstrap command): Fail Fedora Core 7 for amd64 (multilib with 64-bit userspace): Success I still don't know what exactly is causing the 32-bit userspace to fail on Debian Lenny - and I'm not sure what next to do to debug it. However, to achieve the environment that is causing failure, you either have to set up a 64-bit kernel for an x86 system, or set up a 32-bit userspace for an amd64 system. Neither of these scenarios are the default setup for Lenny, and I'm unsure as to how well they're supported or suggested for use. Because of that, I'm inclined to let the matter rest, at least for now. The current build method works for every default setup I've tested so far - I think that is good enough. At least until we encounter some more information. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Test logs for 6.3
On 8/29/07, Rich Edelman [EMAIL PROTECTED] wrote: You can find my build logs (as a .tar.bz2) at http://www.quokworld.com/lfs/6.3/lfs-6.3-build-logs.tar.bz2. Or just browse around http://www.quokworld.com/lfs/6.3/logs/. My machine is a dual Xeon 3.2Ghz (hyperthreaded, heh), 2GB of RAM and a couple 250GB SATA drives. (Dell Precision 470). Thanks, Rich. I've uploaded (and organized) the logs. http://www.linuxfromscratch.org/lfs/build-logs/6.3/DualXeon-3.2GHz/ http://www.linuxfromscratch.org/lfs/build-logs/6.3/DualXeon-3.2GHz/00-README Let me know if you want any information added or removed from the README file. Am I correct that you didn't run the testsuites? I used jhalfs-2.3 and the lfs livecd-x86-r2032 for my build host on this. Unfortunately the SBU values created don't mean all that much because there were a couple of packages (gcc and man-db) that failed to build due to MAKEFLAGS being set to -j5. Setting it down to -j3 allowed GCC to build, but man-db refused to build unless MAKEFLAGS was empty. Anyway, if wanted, I can send in that SBU report.. Total SBUs was like 163 or so (without building the kernel). Yeah, the SBUs are becoming less useful in a multiple processor world. I mainly like them just to know ballpark figures. I.e., the GCC bootstrap takes a long freakin' time compared to most of the other builds. Which reminds me. Manuel, can you add man-db to the MAKEFLAGS blacklist for jhalfs? 2.4.4 fails pretty consistently for me on -j3. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Test logs for 6.3
On Thursday 30 August 2007 12:12, Dan Nicholson wrote: Thanks, Rich. I've uploaded (and organized) the logs. http://www.linuxfromscratch.org/lfs/build-logs/6.3/DualXeon-3.2GHz/ http://www.linuxfromscratch.org/lfs/build-logs/6.3/DualXeon-3.2GHz/00-README Let me know if you want any information added or removed from the README file. Am I correct that you didn't run the testsuites? Oops, I knew I forgot to upload those. :) The test-logs are now available at http://www.quokworld.com/lfs/6.3/lfs-6.3-test-logs.tar.bz2. They're also available via http://www.quokworld.com/lfs/6.3/test-logs/. I only ran the test suites for 065-glibc, 067-binutils, and 068-gcc. If you want, I'll rebuild the whole thing with testsuites for everything, I certainly don't mind. This machine just sits here mostly idle anyway. Rich -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
El Jueves, 30 de Agosto de 2007 19:08, Jeremy Huntwork escribió: Because of that, I'm inclined to let the matter rest, at least for now. The current build method works for every default setup I've tested so far - I think that is good enough. At least until we encounter some more information. I agree, at least as a starting point for 7.0 milestone. Some plans to start merging jh branch into trunk? On a related topic, have you tried to build the jh branch using jhalfs? I has not time yet to try it and I'm not sure if it might work without some fixes on the jhalfs code. -- 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
Released jhalfs-2.3.1
The jhalfs development team is pleased to announce the release of jhalfs-2.3.1. This is a bugs-fixes release to match LFS-6.3 and current BLFS development book. If you are using jhalfs-2.3, please upgrade to jhalfs-2.3.1. The jhalfs-2.3.1 tarball can be downloaded from http://www.linuxfromscratch.org/alfs/downloads/jhalfs/stable/jhalfs-2.3.1.tar.bz2 The list of supported books can be found at http://wiki.linuxfromscratch.org/alfs/wiki/SupportedBooks Please, try it out and send any comments or bugs you find to the alfs-discuss mailing list. -- 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/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Test logs for 6.3
El Jueves, 30 de Agosto de 2007 19:12, Dan Nicholson escribió: Which reminds me. Manuel, can you add man-db to the MAKEFLAGS blacklist for jhalfs? 2.4.4 fails pretty consistently for me on -j3. Was added several days ago, when it start failing also to me ;-) It's on the just-released 2.3.1 version. -- 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: r8349 - in branches/jh/BOOK
[EMAIL PROTECTED] wrote: +paraIf our host is a multilib machine, we want to ensure that we +build 64-bit binaries, so we'll test for that and set a variable if so:/para +paraIf our host is a multilib machine, we want to ensure that we +build 64-bit binaries, so we'll test for that and set a variable if so. +Also, the --with-arch flag is only necessary for x86 machines./para Those para's don't read well at all (and not just because of all the possessive terms: our, we, we'll) :-) Perhaps: Test to see if the host is a multilib machine and set a variable if it is. This ensures that 64-bit binaries are also built. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 07:32:53PM +0200, M.Canales.es wrote: I agree, at least as a starting point for 7.0 milestone. Some plans to start merging jh branch into trunk? I would like to get it in as soon as we can, but considering that there are a number of changes, I was hoping that more people would have had time to look at the branch and comment before we merge. For quick reference again, here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-JH/ and a diff between it and trunk: http://linuxfromscratch.org/~jhuntwork/jh.diff On a related topic, have you tried to build the jh branch using jhalfs? I has not time yet to try it and I'm not sure if it might work without some fixes on the jhalfs code. Yes, I have used jhalfs with it, but not in the last couple of weeks. The only changes to the branch are compatible with jhalfs' current logic, I believe. There's only commnad changes and package version changes, so it should be no problem. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r8349 - in branches/jh/BOOK
On Thu, Aug 30, 2007 at 12:53:05PM -0500, Randy McMurchy wrote: Those para's don't read well at all (and not just because of all the possessive terms: our, we, we'll) :-) Perhaps: Test to see if the host is a multilib machine and set a variable if it is. This ensures that 64-bit binaries are also built. Thanks. It's hard to get into both technical and editor mode at the same time. :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On 8/30/07, Jeremy Huntwork [EMAIL PROTECTED] wrote: On Thu, Aug 30, 2007 at 07:32:53PM +0200, M.Canales.es wrote: I agree, at least as a starting point for 7.0 milestone. Some plans to start merging jh branch into trunk? I would like to get it in as soon as we can, but considering that there are a number of changes, I was hoping that more people would have had time to look at the branch and comment before we merge. It seems pretty sane to me, but I'm about to go into BLFS-6.3 mode, so I don't foresee testing it until that's in better shape. For quick reference again, here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-JH/ and a diff between it and trunk: http://linuxfromscratch.org/~jhuntwork/jh.diff Do you mind syncing the docbook-xsl-snapshot with what's in trunk to reduce the diff a bit? It's the majority of the size right now. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 11:08:34AM -0700, Dan Nicholson wrote: Do you mind syncing the docbook-xsl-snapshot with what's in trunk to reduce the diff a bit? It's the majority of the size right now. Oh, yeah, I didn't even notice that. Will do. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Test logs for 6.3
On 8/30/07, Rich Edelman [EMAIL PROTECTED] wrote: The test-logs are now available at http://www.quokworld.com/lfs/6.3/lfs-6.3-test-logs.tar.bz2. They're also available via http://www.quokworld.com/lfs/6.3/test-logs/. I only ran the test suites for 065-glibc, 067-binutils, and 068-gcc. If you want, I'll rebuild the whole thing with testsuites for everything, I certainly don't mind. This machine just sits here mostly idle anyway. If you feel like doing all the tests, go for it. The more data, the better. I uploaded the test logs: http://www.linuxfromscratch.org/lfs/build-logs/6.3/DualXeon-3.2GHz/chapter06-tests/ -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 12:13:46PM -0600, Jeremy Huntwork wrote: Oh, yeah, I didn't even notice that. Will do. Fixed and the diff regenerated, though the commit seems to be too big to be posted to the list. Also, there are still references to lfs-xsl in the diff due to differences in the committer's name. :/ Oh well. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0 Goals
On Thu, Aug 30, 2007 at 11:14:37AM -0700, Dan Nicholson wrote: * x86_64 support - I think it would be great is we could get a native 64 bit implementation. It's a very common architecture, and really there are few changes from the x86 approach. Jeremy has been working on this in the jh-branch with feedback from Greg and Alexander. I think it's still up in the air how the book style would go. I.e., single book with conditionals or book-per-architecture. A further goal would be multilib, but I don't think that should enter the picture until the pure64 implementation is nicely polished. Actually, one of the benefits of the jh branch is that it works for either x86 or x86_64 with no separation of book or commands. The text endeavors to focus mostly on principles where there are differences (like the dynamic linker name) and the commands are compatible with both architectures. One thing to consider is that because grub legacy is not buildable on x86_64, it has been removed entirely from the book. I would suggest that we make bootloaders a separate section at the end and offer various solutions for various architectures. Because the commands and text have been made generally architecture independent, we could conceivably drop in support for, say, ppc without any adjustments to the commands and simply add its bootloader to the end section. Also, we could possibly add a section at the end that shows what architectures and hosts have been used to build LFS successfully. As for your other suggestions, Dan, you have my support. I think they are worthy goals. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On 8/30/07, Jeremy Huntwork [EMAIL PROTECTED] wrote:
On Thu, Aug 30, 2007 at 12:13:46PM -0600, Jeremy Huntwork wrote:
Oh, yeah, I didn't even notice that. Will do.
Fixed and the diff regenerated, though the commit seems to be too big to
be posted to the list. Also, there are still references to lfs-xsl in
the diff due to differences in the committer's name. :/ Oh well.
Try using svn diff.
svn diff svn://svn.linuxfromscratch.org/LFS/{trunk,branches/jh}
or use -I in diff to ignore the '$Id:' regex:
diff -pNur -I '\$Id:' trunk jh
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 11:40:20AM -0700, Dan Nicholson wrote:
Try using svn diff.
svn diff svn://svn.linuxfromscratch.org/LFS/{trunk,branches/jh}
or use -I in diff to ignore the '$Id:' regex:
diff -pNur -I '\$Id:' trunk jh
Ah, ok. Thanks.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Test logs for 6.3
El Miércoles, 29 de Agosto de 2007 19:15, Dan Nicholson escribió: Thanks. I created the directory, and you should have write privs. http://www.linuxfromscratch.org/lfs/build-logs/6.3/ Please create a directory for your system with a 00-README file describing it like here: http://www.linuxfromscratch.org/lfs/build-logs/6.2/Athlon64-3200+/ Done, published the logs from two machines. The Petium4 one have full chapter06 testsuites, the AMD64 one have both chapter05 and chapter06 testsuites. -- 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: Summary: Debian Lenny as host
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Jeremy Huntwork wrote: On Thu, Aug 30, 2007 at 07:32:53PM +0200, M.Canales.es wrote: I agree, at least as a starting point for 7.0 milestone. Some plans to start merging jh branch into trunk? I would like to get it in as soon as we can, but considering that there are a number of changes, I was hoping that more people would have had time to look at the branch and comment before we merge. For quick reference again, here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-JH/ and a diff between it and trunk: http://linuxfromscratch.org/~jhuntwork/jh.diff I've been reading through the diff, and I saw this in binutils-pass1: +screenuserinputtest $(uname -m | grep 64) amp;amp; M64=-m64/userinput/screen Why not just: uname -m | grep -q 64 amp;amp; M64=-m64 instead? The -q option to grep will prevent any output, and just return an appropriate exit code. Also, I see that the console log level change hasn't been merged into the jh branch either (that was r8222, and perhaps a few revs around it also -- chapter07/console.xml). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1zE1S5vET1Wea5wRA7MiAJ9dXxbR/tfAGbx0owVciFfSZ2p8rACfaCsM /CEzMyUOnnOCGV2eOdvm/iI= =r/SE -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On 8/30/07, Bryan Kadzban [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Jeremy Huntwork wrote: On Thu, Aug 30, 2007 at 07:32:53PM +0200, M.Canales.es wrote: I agree, at least as a starting point for 7.0 milestone. Some plans to start merging jh branch into trunk? I would like to get it in as soon as we can, but considering that there are a number of changes, I was hoping that more people would have had time to look at the branch and comment before we merge. For quick reference again, here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-JH/ and a diff between it and trunk: http://linuxfromscratch.org/~jhuntwork/jh.diff I've been reading through the diff, and I saw this in binutils-pass1: +screenuserinputtest $(uname -m | grep 64) amp;amp; M64=-m64/userinput/screen Why not just: uname -m | grep -q 64 amp;amp; M64=-m64 instead? The -q option to grep will prevent any output, and just return an appropriate exit code. Except that you're still using the host grep, which may not have the -q option (don't remember when it was added). grep 64 /dev/null works, too. I also was thinking that you would want to do `|| M64=' in case there was a stray M64 variable in the environment, but maybe that's too paranoid. Also, I see that the console log level change hasn't been merged into the jh branch either (that was r8222, and perhaps a few revs around it also -- chapter07/console.xml). It seems to also be missing a udev-config fix to handle usb devices in 2.6.22+ kernels. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 05:05:58PM -0400, Bryan Kadzban wrote: uname -m | grep -q 64 amp;amp; M64=-m64 instead? The -q option to grep will prevent any output, and just return an appropriate exit code. Yeah, that's definitely simpler. Not sure why I did it the original way. Sometimes I think I just get stuck on a certain method. Also, I see that the console log level change hasn't been merged into the jh branch either (that was r8222, and perhaps a few revs around it also -- chapter07/console.xml). Thanks, I'll take a look. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 02:16:13PM -0700, Dan Nicholson wrote: Except that you're still using the host grep, which may not have the -q option (don't remember when it was added). I knew there was a reason! :P -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 02:16:13PM -0700, Dan Nicholson wrote: It seems to also be missing a udev-config fix to handle usb devices in 2.6.22+ kernels. Do you recall which revision that was? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On 8/30/07, Jeremy Huntwork [EMAIL PROTECTED] wrote: On Thu, Aug 30, 2007 at 02:16:13PM -0700, Dan Nicholson wrote: It seems to also be missing a udev-config fix to handle usb devices in 2.6.22+ kernels. Do you recall which revision that was? 8258 http://wiki.linuxfromscratch.org/lfs/changeset/8258 -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 02:33:18PM -0700, Dan Nicholson wrote: Do you recall which revision that was? 8258 Ah, that explains it. I know I copied the entire repository, but I've only been changing items in BOOK and therefore only merged commits to BOOK. When it gets merged back to trunk, we'll only need to concentrate on changes to items under BOOK. I think it is all up to date now and the only differences are changes relevant to the new features added in the jh branch. I've generated a new diff, too: http://linuxfromscratch.org/~jhuntwork/jh.diff -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
Dan Nicholson wrote: Except that you're still using the host grep, which may not have the -q option (don't remember when it was added). FWIW circa 2000 Red Hat 6.2 (grep-2.4) has it. PS - This addition seems like overkill as most multilib setups default to m64. It appears Jeremy is catering to those unsupportable with current build method non-standard 32/64-bit setups such as Alex's Debian Lenny example. 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: Summary: Debian Lenny as host
On Fri, Aug 31, 2007 at 08:11:22AM +1000, Greg Schafer wrote: PS - This addition seems like overkill as most multilib setups default to m64. It appears Jeremy is catering to those unsupportable with current build method non-standard 32/64-bit setups such as Alex's Debian Lenny example. Yes, it was added originally to cover that scenario, but I'm no longer catering to that host. When it came time to commit a few necessary changes today, I decided to leave it in since it will always force binutils and gcc to build 64-bit on pass1. As you say it is probably unnecessary even there, but at least by including it, we know without doubt that we're getting 64-bit, even on multilib hosts. Thereafter, of course, it isn't necessary at all since we'll be using our 64-bit only compiler. If you think it's better to leave it out entirely, please explain why. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0 Goals
On Thu, Aug 30, 2007 at 11:14:37AM -0700, Dan Nicholson wrote: * x86_64 support - I think it would be great is we could get a native 64 bit implementation. It's a very common architecture, and really there are few changes from the x86 approach. Jeremy has been working on this in the jh-branch with feedback from Greg and Alexander. I think it's still up in the air how the book style would go. I.e., single book with conditionals or book-per-architecture. A further goal would be multilib, but I don't think that should enter the picture until the pure64 implementation is nicely polished. One other thing to consider: As you may know, GCC 4.2.1 bootstraps by default. To disable bootstrapping, you have to explicitly run '--disable-bootstrap'. I've already adjusted the 'make bootstrap' command in gcc pass1 to be just 'make', but in order to mimic our current build we'd also have to add '--disable-bootstrap' to pass 2 and chapter 6 gcc. So far, I've left it as is, meaning that all three builds of gcc are bootstrapped. This, certainly, is overkill, but as has been already mentioned elsewhere, the fact that bootstrapping is the default from upstream should say something. Perhaps we could do something like: * Bootstrap pass1 * Use '--disable-bootstrap' for pass2 * Bootstrap the final gcc Thoughts? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0 Goals
Jeremy Huntwork wrote: So far, I've left it as is, meaning that all three builds of gcc are bootstrapped. Say what? Ugh, that's just unnecessary in the extreme! We covered this years ago.. This, certainly, is overkill, but as has been already mentioned elsewhere, the fact that bootstrapping is the default from upstream should say something. You misunderstand. You need to look at it in the context of the overall build method. GCC devs certainly want you to bootstrap.. and you already have.. once! Just step away for a moment and think about the true meaning of the word bootstrap. Perhaps we could do something like: * Bootstrap pass1 * Use '--disable-bootstrap' for pass2 * Bootstrap the final gcc Thoughts? Strongly disagree. That means your final Glibc (the most important lib in the whole system) was compiled with a non-bootstrapped GCC. That is not logical (and it's also what CLFS does IIRC). Please see the second last para in this posting for some more comments: http://linuxfromscratch.org/pipermail/lfs-dev/2005-August/052536.html The bottom line is this: the current build method works on the assumption that a non-bootstrapped GCC-Pass2 and Ch 6 GCC produce identical byte-for-byte compilers compared to what would have been produced had they been bootstrapped. This is a test I perform myself from time to time and it needs to be done every time we upgrade to a new major GCC version. 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: 7.0 Goals
On Fri, Aug 31, 2007 at 10:23:27AM +1000, Greg Schafer wrote: Say what? Ugh, that's just unnecessary in the extreme! We covered this years ago.. Relax. I would have thought that my previous post showed that I don't intend to leave it as it is, but I wanted to foster discussion on what it should be. You need to look at it in the context of the overall build method. Yes, I agree. And you're right - there were certain aspects of the entire production that I didn't consider. Strongly disagree. That means your final Glibc (the most important lib in the whole system) was compiled with a non-bootstrapped GCC. Er, no. By your own arguments, it would still be a byte-for-byte identical compiler. The -fomit-frame-pointer tweak is still present in the jh branch... and, I do note that it wouldn't be necessary if we're bootstrapping. The bottom line is this: the current build method works on the assumption that a non-bootstrapped GCC-Pass2 and Ch 6 GCC produce identical byte-for-byte compilers compared to what would have been produced had they been bootstrapped. This is a test I perform myself from time to time and it needs to be done every time we upgrade to a new major GCC version. The main reason why I suggested bootstrapping for the final gcc is because it seemed reasonable to me to try to fit as closely as possible to upstream's intentions for the final compiler. If we can do that and still bypass bootstrapping, wonderful. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
