Re: Safer linux-headers install
> - Original Message - > From: "Dan Nicholson" <[EMAIL PROTECTED]> > To: "LFS Developers Mailinglist" > Sent: Wednesday, July 11, 2007 3:16 PM > Subject: Re: Safer linux-headers install > > >> 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. Luca -- 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
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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Randy McMurchy wrote: > This should not spark a flame war, you make a very concise and to the > point statement/question that deserves discussion. However, the CLFS > fork was mostly due to some dev's dissatisfaction with the decisions > that were made a *long* time ago. It's my belief there is still > animosity. > What animosity, CLFS is not a fork, we are a different form of LFS. If you consider us running our own website and servers a fork, I guess we are one. But this was all authorized by Gerard. > I have thought about this many, many times. To the point of sending > private emails to some of the CLFS devs/major users. *All* of them > that I contacted have said that a merge or even an attempt at a merge > of our (LFS/BLFS devs) efforts with the CLFS team would never work, > or even be contemplated. > The one thing everyone has stated Randy, is our methodologies are different, LFS caters to x86 processors, CLFS caters to more than just x86. Everything after the cross-tools, and tools chapters are almost exactly the same. Except for the udev and bootscripts package. > That said, for (B)LFS devs who weren't envited to join CLFS, they will > never be able to, if what I've been told is true. Recently, I've > been away from the project, some of it due to the fact that I'm using > 64 bit arch's and my work on these platforms is now of no value to > BLFS, nor am I able to contribute meaningfully to CLFS. > > Randy, CLFS has an open door development policy. No one is limited. All you have do is contribute. > Yes, I agree the (B)LFS days are limited. I've been trying to get > the BLFS book somewhat up to date in the last couple of weeks, as I > believe there's still a niche out there. x86 archs will be in use > for some time to come in various capacities, especially in dedicated > server use. > > Randy I think your in the same boat as Ryan and myself are right now. We have been to busy with our day jobs to keep up to date on changes required for the projects. > You ask if there are "any plans to eventually begin work on CLFS when > the time is right". Unfortunately, I don't believe it is an option at > this point. > > CLFS has offered it's services to help the LFS and BLFS teams numerous times, we have never been given any tasks or have been asked to help. I'm just disgusted you decided to bring up the past, that was all behind us. -- 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
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
{B,C}LFS State of Things (was Re: SVN-20070706: ...)
Craig Jackson wrote these words on 07/13/07 18:02 CST: > I don't know how to say this > delicately, so I will just say it. And being one that appreciates such candor, I applaud your message. > 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? This should not spark a flame war, you make a very concise and to the point statement/question that deserves discussion. However, the CLFS fork was mostly due to some dev's dissatisfaction with the decisions that were made a *long* time ago. It's my belief there is still animosity. I have thought about this many, many times. To the point of sending private emails to some of the CLFS devs/major users. *All* of them that I contacted have said that a merge or even an attempt at a merge of our (LFS/BLFS devs) efforts with the CLFS team would never work, or even be contemplated. That said, for (B)LFS devs who weren't envited to join CLFS, they will never be able to, if what I've been told is true. Recently, I've been away from the project, some of it due to the fact that I'm using 64 bit arch's and my work on these platforms is now of no value to BLFS, nor am I able to contribute meaningfully to CLFS. Yes, I agree the (B)LFS days are limited. I've been trying to get the BLFS book somewhat up to date in the last couple of weeks, as I believe there's still a niche out there. x86 archs will be in use for some time to come in various capacities, especially in dedicated server use. You ask if there are "any plans to eventually begin work on CLFS when the time is right". Unfortunately, I don't believe it is an option at this point. -- 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] 18:17:00 up 1 day, 11:24, 1 user, load average: 0.06, 0.01, 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
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 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
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 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
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: 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. 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
