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
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: 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
Re: SVN-20070706: Step 5.7 Adjusting the Toolchain
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 Jon, 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 I've been compiling and running LFS on ppc and sparc for six years already and this notice has been there for at least three or four years. However, further to this discussion, there is actually a problem with the sed command on platforms other than x86. Here's how it is right now: sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools@g' and here's how I would change it so it works everywhere: sed 's@/lib/ld-linux.so.2@/tools@g' The linker on non-x86 platforms is not defined at the start of a new line, all by itself. Now, can I make another suggestion, can we define a variable LD_LINKER or something like that that we can write into .bashrc and which will default to ld-linux.so.2, but with a note saying that it's something else on different platforms? You can put a disclaimer that building and running LFS on non-x86 platforms is not supported, if you want. So the sed command will look like: sed 's@/lib/$LD_LINKER@/tools@g' IvanK. -- 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
On Thu, Jul 12, 2007 at 08:49:06PM -0600, Jon Fullmer wrote: I don't understand. I'm aware of CLFS (and even for the PowerPC). This is assuming I want to build a system on a platform other than its destined platform. I'm actually building it on a PowerPC box running LFS-6.2. That's not the point. But, given that most LFS (and BLFS) developers think using anything other than x86 is unsupportable, CLFS is the only way to go for other architectures. And yes, pretending to cross-compile does work for native builds. There is a long tradition of using LFS on ppc, but the book doesn't directly support it. The reason I mentioned that I was doing this on PowerPC was to put all the variables on the table. I'm not sure if this is unique to PowerPC. I suspect that it's actually unique to gcc-4.1. The point is, if you do a gcc -dumpspecs, the linker information is no longer at the beginning of the line. It's in the middle. And as others have already noted, yes you are absolutely correct that the linker information is not at the start of the line. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- 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
Ken Moffat wrote: But, given that most LFS (and BLFS) developers think using anything other than x86 is unsupportable, CLFS is the only way to go for other architectures. Ken, That is a little unfair. I don't know of any LFS or BLFS developers that think non-x86 is unsupportable. We have chosen to keep those books x86 only due to the personal preferences, the hardware available to them, and a preference of wanting to use the simplest instructions possible without IF $arch == 'x' constructs. We have no problems with pointing people to CLFS when it is appropriate. -- Bruce -- 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
On 7/13/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Ken Moffat wrote: But, given that most LFS (and BLFS) developers think using anything other than x86 is unsupportable, CLFS is the only way to go for other architectures. Ken, That is a little unfair. I don't know of any LFS or BLFS developers that think non-x86 is unsupportable. We have chosen to keep those books x86 only due to the personal preferences, the hardware available to them, and a preference of wanting to use the simplest instructions possible without IF $arch == 'x' constructs. We have no problems with pointing people to CLFS when it is appropriate. I have been using CLFS to make x86-only builds lately as well. I am not pretending to be all that involved in the test/dev of lfs or clfs, but hopefully can give a user's perspective: Like most, I started learning LFS with LFS, not CLFS. It is STILL a very useful and (mostly) complete project, rolled up in a package deal in the form of the stable versions. I have immense respect for all the devs for LFS that still put countless hours into making it very successful. I know that the time spent now, even if it's only on x86, could never be wasted, as there is plenty to learn just from that one platform. I spend a fair amount of time in #lfs-support, and I never suggest that people switch to CLFS unless they can't build with LFS due to their architecture. That being said, my focus has completely shifted ever since working with CLFS. I needed it to work with my new 64-bit proc. At that point I still had no preference. I don't know how to say this delicately, so I will just say it. It seems futile for me to attempt to test for LFS for the simple fact that the x86 architecture's days are limited. You can barely buy a new system off the retail shelf that isn't at least a single-core athlon64. I am very curious where the efforts will change with regard to the very dedicated LFS developers. Do you have any plans to eventually begin work on CLFS when the time is right? It seems like a natural progession to combine forces at some point, and I hope egos do not get in the way of this, as I know we would value the wealth of knowledge that LFS devs and testers could bring to CLFS, as well as the reduction in overhead in maintaining 2 separate projects. I hope I didn't spark a flame war here. That is definately not my intent. It just seemed like a relevant time in the thread to bring it up. I don't want to see both projects suffer over issues of pride. Thank you all for your efforts! Craig Jackson (TheEpitome) -- 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
On 7/13/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Ken Moffat wrote: But, given that most LFS (and BLFS) developers think using anything other than x86 is unsupportable, CLFS is the only way to go for other architectures. Ken, That is a little unfair. I don't know of any LFS or BLFS developers that think non-x86 is unsupportable. We have chosen to keep those books x86 only due to the personal preferences, the hardware available to them, and a preference of wanting to use the simplest instructions possible without IF $arch == 'x' constructs. We have no problems with pointing people to CLFS when it is appropriate. 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. -- Dan -- 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
On Fri, Jul 13, 2007 at 05:36:23PM -0500, Bruce Dubbs wrote: Ken Moffat wrote: But, given that most LFS (and BLFS) developers think using anything other than x86 is unsupportable, CLFS is the only way to go for other architectures. Ken, That is a little unfair. I don't know of any LFS or BLFS developers that think non-x86 is unsupportable. We have chosen to keep those books x86 only due to the personal preferences, the hardware available to them, and a preference of wanting to use the simplest instructions possible without IF $arch == 'x' constructs. We have no problems with pointing people to CLFS when it is appropriate. -- Bruce If I summarised unfairly, I apologise. Would you prefer is unsupportable by most of the LFS/BLFS editors ? This is in the sense of not able to be supported, NOT one of the meanings which drift towards 'indefensible'. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- 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
Craig Jackson wrote: It seems futile for me to attempt to test for LFS for the simple fact that the x86 architecture's days are limited. You can barely buy a new system off the retail shelf that isn't at least a single-core athlon64. Um, you seem to be talking as if one must run a 64-bit OS on 64-bit hardware. That is, of course, utterly ridiculous. IMHO 32-bit OS'es running on 64-bit hardware are still the norm. See this recent post from an Intel employee for example: http://lkml.org/lkml/2007/7/11/694 Not only that, you also seem to be implying the days of the LFS *build method* are limited. I might be biased but I can assure you that the basic idea of the LFS/DIY build method works fine on x86, ppc and x86_64 for *NATIVE* building of Glibc based systems and that it has stood the test of time. Of course, it doesn't cope with multilib nor x86 - x86_64 bootstraps but that is where cross compilation comes in handy. I will not go into the many drawbacks of cross versus native because it's all been said before. I agree with Dan. It's probably time to implement a native non-multilib x86_64 build as an option for LFS. But to keep everything compatible with x86, you'll probably need the lib - lib64 symlinks which mirrors the practice of some distros and also what I've done in the DIY Refbuild. 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: SVN-20070706: Step 5.7 Adjusting the Toolchain
Ken Moffat wrote: On Fri, Jul 13, 2007 at 05:36:23PM -0500, Bruce Dubbs wrote: Ken Moffat wrote: But, given that most LFS (and BLFS) developers think using anything other than x86 is unsupportable, CLFS is the only way to go for other architectures. Ken, That is a little unfair. I don't know of any LFS or BLFS developers that think non-x86 is unsupportable. We have chosen to keep those books x86 only due to the personal preferences, the hardware available to them, and a preference of wanting to use the simplest instructions possible without IF $arch == 'x' constructs. We have no problems with pointing people to CLFS when it is appropriate. -- Bruce If I summarised unfairly, I apologise. Would you prefer is unsupportable by most of the LFS/BLFS editors ? This is in the sense of not able to be supported, NOT one of the meanings which drift towards 'indefensible'. I wouldn't use the word unsupportable at all. You can say that the LFS/BLFS Editors have chosen to only target x86 for a variety of reasons. The way I look at the whole project, it is a curriculum on how to build a system from source. LFS is the intro course where things are presented in a 'straight line' manner. BLFS is a follow on to that. Things like HLFS, ALFS, and CLFS can be considered advanced courses. Sure, some people can jump right into CLFS, but many can't. I think that LFS/BLFS will stay relevant for quite some time, even if the common hardware is x86_64 compatible. As Greg points out, many, if not most people run 32-bit OSes on 64-bit capable hardware. For general purpose work, I know of no compelling performance reason to use 64-bit applications or OSes. Of course, many of the LFS community will want to experiment with x86_64 or other hardware. The way the different approaches have divided themselves is not unreasonable. -- Bruce -- 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
Um, you seem to be talking as if one must run a 64-bit OS on 64-bit hardware. That is, of course, utterly ridiculous. IMHO 32-bit OS'es running on 64-bit hardware are still the norm. See this recent post from an Intel employee for example: I'm not implying that, in fact i completely agree with you. I am merely speaking to some of the reason the I personally felt compelled to switch. LFS is primarily educational for me, until the point when I am using it in a production environment (which is not now). :) With this education comes a desire to stay up-to-date, rather than just build the most stable OS possible (I would use LFS 5 if that were the goal). Not only that, you also seem to be implying the days of the LFS *build method* are limited. I might be biased but I can assure you that the basic idea of the LFS/DIY build method works fine on x86, ppc and x86_64 for *NATIVE* building of Glibc based systems and that it has stood the test of time. Of course, it doesn't cope with multilib nor x86 - x86_64 bootstraps but that is where cross compilation comes in handy. I will not go into the many drawbacks of cross versus native because it's all been said before. No I don't have issue with the LFS build method. All the (x)lfs projects use this method to some extent, and it is one that I like more and more after each successful build. It is very easy to understand and cannot be much simpler when building toolchain packages etc. This is a great idea and the fact that CLFS is so remarkably similar is a testament to LFS's proven concept. I am not writing this to whine and complain, it truly saddens me to think that two groups of like minded people completely split because of a detail such as this. I just hope that when users and testers start migrating to CLFS more and more, which is inevitable, that the LFS work performed since the fork will not be in vain, and that the hundreds of thousands of hours of learning and development by the LFS devs will not be in vain. I agree with Dan. It's probably time to implement a native non-multilib x86_64 build as an option for LFS. But to keep everything compatible with x86, you'll probably need the lib - lib64 symlinks which mirrors the practice of some distros and also what I've done in the DIY Refbuild. I have no loyalties to either group. I work on whatever project suits my purposes at any moment. If the LFS project started to make native 64 or multilib builds, I would bet that the shear maturity of the LFS project would win most of the users of CLFS right back. Stylisticly, and for stability's and compatibility's sake, I actually prefer LFS to CLFS. Functionally, CLFS is more progressive, and I am a progressive user, as most people who try any LFS are naturally progressive users as well. Thanks! Craig Jackson (TheEpitome) -- 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
Jon Fullmer wrote: When putting this system for a non-x86 (PowerPC, to be specific), I noticed that this setup is actually wrong. You may want to check out http://trac.cross-lfs.org/ for the PowerPC. -- Bruce -- 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
I don't understand. I'm aware of CLFS (and even for the PowerPC). This is assuming I want to build a system on a platform other than its destined platform. I'm actually building it on a PowerPC box running LFS-6.2. That's not the point. The reason I mentioned that I was doing this on PowerPC was to put all the variables on the table. I'm not sure if this is unique to PowerPC. I suspect that it's actually unique to gcc-4.1. The point is, if you do a gcc -dumpspecs, the linker information is no longer at the beginning of the line. It's in the middle. The problem is that step 5.7 is about making sure that your linking against the /tools/lib/ linker, not the /lib linker. Because the sed statement specifies the substitution only if the text matches at the beginning of the line, the linker is not substituted. I discovered this because I followed the steps, ran the gcc test, and discovered that I was still linking to the /lib linker. Has anyone running this on x86 come across this? Is there anyone with a gcc 4.1 install that can verify whether the linkers mentioned in the dumpspecs file still only show up at the beginning of the line? They don't for me. - Jon On Jul 12, 2007, at 8:07 PM, Bruce Dubbs wrote: Jon Fullmer wrote: When putting this system for a non-x86 (PowerPC, to be specific), I noticed that this setup is actually wrong. You may want to check out http://trac.cross-lfs.org/ for the PowerPC. -- Bruce -- 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: SVN-20070706: Step 5.7 Adjusting the Toolchain
Jon Fullmer wrote: I don't understand. Jon, LFS is targeted at x86 and therefore the instructions are only tested there and not guaranteed to work on other arches. I've done ppc builds myself and can confirm that specs files do indeed differ per arch and GCC version. Of course, even the *name* of the dynamic linker is different for ppc. FYI I added support for ppc native builds to the DIY Refbuild a while back, although I haven't tested it lately. See sig below for a pointer. 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: SVN-20070706: Step 5.7 Adjusting the Toolchain
On Jul 12, 2007, at 9:06 PM, Greg Schafer wrote: I've done ppc builds myself and can confirm that specs files do indeed differ per arch and GCC version. Of course, even the *name* of the dynamic linker is different for ppc. THAT'S what I wanted to know. Yes, I know that x86 uses ld-linux.so. 2 and PPC uses ld.so.1 (which is why I deliberately left the name of the linker out of my first message; didn't want to create excessive confusion). But you say the the arrangement of the spec files do differ per architecture? Great. That's what I didn't know. Thanks, guys. - 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
On Jul 12, 2007, at 8:46 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. At section 5.2 people are to be aware of the linker. Also, as a PPC builder, you know you'll build more packages than what is mentioned in the book. It is good practice to manually check the specs file and any other patches that affect the linker. This information might be targeted to someone who has a great idea of what is going on with the specs patches and the toolchain adjustments and they will adjust the build accordingly. The setup is correct. The linker may need to be changed, though. Sincerely, William -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
