Re: SVN-20070706: Step 5.7 Adjusting the Toolchain
El Sábado, 14 de Julio de 2007 01:26, Dan Nicholson escribió: I would actually really like to add x86_64 (non-multilib to start) support to LFS and BLFS. It's becoming increasingly uncommon to even be able to purchase a non-64bit processor at this point. We can basically copy what Greg's done on DIY (which is where I go looking for native toolchain stuff anyway), and maybe we could use Manuel's XSLfoo to not have a whole bunch of $ARCH conditionals. That's what I think, anyway. When was proposed to convert the cross-build branch into a separate CLFS book instead to merge it into the main LFS book, I mentioned that LFS should start including at least pure and multilib x86_64 native builds to not die: http://linuxfromscratch.org/pipermail/lfs-dev/2005-September/053368.html IMHO, we need to release LFS-6.3 ASAP and start working on 7.x book series including x86_64 support. -- 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: SVN-20070706: Step 5.7 Adjusting the Toolchain
El Viernes, 13 de Julio de 2007 18:18, Ivan Kabaivanov escribió: actually there's a notice just before the command you've quoted. This is what I'm referring to: quote If working on a platform where the name of the dynamic linker is something other than ld-linux.so.2, replace ld-linux.so.2 with the name of the platform's dynamic linker in the following commands. Refer to Section 5.2, Toolchain Technical Notes, if necessary. /quote However, further to this discussion, there is actually a problem with the sed command on platforms other than x86. Right. If architectures others than x86 aren't oficialy supported by the LFS book, then that quote should be removed. If the quote is not removed we implicity are assuming that the book could be used as is to do native builds on other arches, what is not true. -- 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: Preparing for 6.3 Release
On 6/8/07, Dan Nicholson [EMAIL PROTECTED] wrote: So, I think it's about time we start pushing out a 6.3 release. What do you guys think? Here are the outstanding issues I can think of. Matthew, ping? Any thoughts on this? I think most of the issues brought up in this thread have been addressed. I'd like to see if glibc-2.5.1 will happen, but we can certainly just use the latest branch_update patch. The LiveCD is still kind of up in the air, but I think most of the big concerns have been addressed, and now Jeremy is back on the prowl helping out. Would it help to have someone else handle the release? I'm pretty tied up until August, but could probably play a bigger role then. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Safer linux-headers install
On 7/11/07, Luca/Gmail [EMAIL PROTECTED] wrote: From: Dan Nicholson [EMAIL PROTECTED] Unless it's going to be accepted upstream, then I'm not really interested in adding a patch here which takes one extra command to workaround. Which, now that I look again, makes this much easier to solve. # make INSTALL_HDR_PATH=/usr oldheaders= headers_install It can be used make INSTALL_HDR_PATH=/usr oldheaders= unwanted= headers_install too; it's definitely simpler. So, I thought about this a little and decided to just use the hammer approach of INSTALL_HDR_PATH=dest, cp dest/include/* /usr/include. I don't feel real comfortable depending on variables internal to their headers script. We can change this if the consensus changes, but for now I'm just going to push in the simple version. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Safer linux-headers install
- Original Message - From: Dan Nicholson [EMAIL PROTECTED] To: LFS Developers Mailinglist lfs-dev@linuxfromscratch.org Sent: Saturday, July 14, 2007 5:38 PM Subject: Re: Safer linux-headers install So, I thought about this a little and decided to just use the hammer approach of INSTALL_HDR_PATH=dest, cp dest/include/* /usr/include. I don't feel real comfortable depending on variables internal to their headers script. We can change this if the consensus changes, but for now I'm just going to push in the simple version. -- Dan Hello Dan. Thanks for the reply and taking it under consideration. Instead I'm sorry but haven't had the time to check about the headers installed with wrong permissions issue; Thor's hammer on me :) Anyway I promise I'll check and eventually report it; the only thing I can say is that I read many people having this one. Regards, Luca P.S. Last days I changed email address globally but mails were rejected as spam and I had to change it again; I sent a mail to the postmaster but had no response... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
SVN-20070706: Step 5.7 Adjusting the Toolchain
Gentlemen, Forgive a novice to this list. I couldn't find any mention of this, so if it's already been talked about, I'm sorry. Step 5.7 of the recent development book shows this step currently to generate the specs file: gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools@g' \ `dirname $(gcc -print-libgcc-file-name)`/specs When putting this system for a non-x86 (PowerPC, to be specific), I noticed that this setup is actually wrong. I discovered this when the compile test of the dummy.c code showed the interpreter as still being /lib/ld... (as opposed to /tools/lib/ld...). In looking at the generated stream, I noticed that the /lib/ld... mentionings do not occur at the beginning of the line, as the sed statement requires. I would think that you would need to remove the ^, like this: gcc -dumpspecs | sed 's@/lib/ld-linux.so.2@/tools@g' \ `dirname $(gcc -print-libgcc-file-name)`/specs That's what I did, anyway, and it worked great. This is my first shot at participating in the Development version, so if I'm full of it, or I've totally missed something obvious, feel free to point it out to me. I love LFS, and would love to see it continue in its greatness. Thanks. - Jon-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20070706: Step 5.7 Adjusting the Toolchain
Sorry for the repeat, folks. I sent this the first time in an HTML message, and evidently it took five days to get through the review process. After two days, I resent it in plaintext, and that's what spurred the conversation. Please ignore. - Jon On Jul 10, 2007, at 10:15 PM, Jon Fullmer wrote: Gentlemen, Forgive a novice to this list. I couldn't find any mention of this, so if it's already been talked about, I'm sorry. Step 5.7 of the recent development book shows this step currently to generate the specs file: gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools@g' \ `dirname $(gcc -print-libgcc-file-name)`/specs When putting this system for a non-x86 (PowerPC, to be specific), I noticed that this setup is actually wrong. I discovered this when the compile test of the dummy.c code showed the interpreter as still being /lib/ld... (as opposed to /tools/lib/ld...). In looking at the generated stream, I noticed that the /lib/ld... mentionings do not occur at the beginning of the line, as the sed statement requires. I would think that you would need to remove the ^, like this: gcc -dumpspecs | sed 's@/lib/ld-linux.so.2@/tools@g' \ `dirname $(gcc -print-libgcc-file-name)`/specs That's what I did, anyway, and it worked great. This is my first shot at participating in the Development version, so if I'm full of it, or I've totally missed something obvious, feel free to point it out to me. I love LFS, and would love to see it continue in its greatness. Thanks. - Jon -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
Dan Nicholson wrote these words on 07/14/07 10:34 CST: I think most of the issues brought up in this thread have been addressed. I'd like to see if glibc-2.5.1 will happen, but we can certainly just use the latest branch_update patch. Just out of curiosity, why are we continually updating the Glibc patch? After this branch_update 3 patch, Glibc probably isn't even close to a stable release any more. Doesn't this sort of go against a long-standing policy? -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 12:08:01 up 2 days, 5:15, 1 user, load average: 0.68, 0.23, 0.07 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
Dan Nicholson wrote these words on 07/14/07 12:52 CST: It's their stable branch which contains many backported bug fixes and they're not producing any more releases. Is it better to use a known buggy glibc-2.5? If glibc-2.5.1 was imminent, I'd say wait, but recent history would suggest it's not likely. I'm just mentioning it, doesn't really matter to me. However I'm curious about something else. These branch update patches are huge, these are all bug fixes? There's no enhancements in these patches? I'm asking because I don't know the answer, but it would be nice to know. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 13:13:00 up 2 days, 6:20, 1 user, load average: 0.02, 0.03, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20070706: Step 5.7 Adjusting the Toolchain
Sorry for the repeat, folks. I sent this the first time in an HTML message, and evidently it took five days to get through the review process. After two days, I resent it in plaintext, and that's what spurred the conversation. I only go through lfs-dev's pending moderation list about once a week. It's mostly spam anyways and by the time me or somebody else gets around checking the list, the occasional real post will have been reposted. Except this time I didn't read all the unread lfs-dev emails. So, my bad. And it'll most probably happen again at that ;) Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
