From diy-linux-dev@diy-linux.org Fri Dec 1 00:23:24 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Fri, 1 Dec 2006 10:23:24 +1100 Subject: Fedora Core 6 Host In-Reply-To: <91705d080611301453o25274371k761035169f332dae@mail.gmail.com> References: <20061130221859.GA11259@tigers.local> <91705d080611301453o25274371k761035169f332dae@mail.gmail.com> Message-ID: <20061130232324.GA11621@tigers.local> On Thu, Nov 30, 2006 at 02:53:44PM -0800, Dan Nicholson wrote: > On 11/30/06, Greg Schafer wrote: > >I believe the frequency of folks bootstrapping from very old distros is far > >less than those bootstrapping from say FC6. Therefore it might make sense > >to > >cater to the majority. Ideally, I'd much rather have a clean solution that > >works everywhere, but sadly, I can't find it :-( If anyone can think of a > >good solution then please let me know. > > I think you're the only one left trying to build against a 2000 era > toolchain. :) I can't think of any better solution, but it seems to > make the most sense to cut off really old gcc's. It's just another > host requirement in my mind. The only reason I do it is because I firmly believe it improves the overall bootstrapability of the build. If it builds from RH62, it should build from anything, right? Wrong! :-) But you get my drift.. > I think if I'm understanding the tags in the gcc repo, it's in > gcc-3.0.1 in the stable releases. That's fairly reasonable, and needed > to build a 2.6 kernel with thread local storage, right? Not sure about the GCC versions. I'll do some tests to get more info. The kernel is not directly relevant IMHO. It's true that a running 2.6 kernel is required for TLS and one can't even build a native NPTL Glibc without it. I've mentioned this before (but *still* haven't documented it in the refbuild) but one can build and boot a new kernel immediately after GCC-pass1 to solve this requirement. Regards Greg From diy-linux-dev@diy-linux.org Fri Dec 1 00:35:11 2006 From: diy-linux-dev@diy-linux.org (Dan Nicholson) Date: Thu, 30 Nov 2006 15:35:11 -0800 Subject: Fedora Core 6 Host In-Reply-To: <20061130232324.GA11621@tigers.local> References: <20061130221859.GA11259@tigers.local> <91705d080611301453o25274371k761035169f332dae@mail.gmail.com> <20061130232324.GA11621@tigers.local> Message-ID: <91705d080611301535l4a59bd04tbe2f9af6d4147bd5@mail.gmail.com> On 11/30/06, Greg Schafer wrote: > On Thu, Nov 30, 2006 at 02:53:44PM -0800, Dan Nicholson wrote: > > > > I think you're the only one left trying to build against a 2000 era > > toolchain. :) I can't think of any better solution, but it seems to > > make the most sense to cut off really old gcc's. It's just another > > host requirement in my mind. > > The only reason I do it is because I firmly believe it improves the overall > bootstrapability of the build. If it builds from RH62, it should build from > anything, right? Wrong! :-) But you get my drift.. Agreed. > > I think if I'm understanding the tags in the gcc repo, it's in > > gcc-3.0.1 in the stable releases. That's fairly reasonable, and needed > > to build a 2.6 kernel with thread local storage, right? > > Not sure about the GCC versions. I'll do some tests to get more info. I slogged through the online svn viewer for a little while to figure this out. It's in gcc_3_0_1_release, but not in gcc-2_95_3 or anything earlier. http://gcc.gnu.org/viewcvs/tags/gcc_3_0_1_release/gcc/gcc.c?view=log http://gcc.gnu.org/viewcvs/tags/gcc-2_95_3/gcc/gcc.c?view=log > The kernel is not directly relevant IMHO. It's true that a running 2.6 > kernel is required for TLS and one can't even build a native NPTL Glibc > without it. I've mentioned this before (but *still* haven't documented it in > the refbuild) but one can build and boot a new kernel immediately after > GCC-pass1 to solve this requirement. True. That's probably the most robust method, too, but something of a PITA. I'd be curious which distro versions contain gcc-3.x in either case. -- Dan From diy-linux-dev@diy-linux.org Fri Dec 1 00:53:19 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Fri, 1 Dec 2006 10:53:19 +1100 Subject: Fedora Core 6 Host In-Reply-To: <91705d080611301535l4a59bd04tbe2f9af6d4147bd5@mail.gmail.com> References: <20061130221859.GA11259@tigers.local> <91705d080611301453o25274371k761035169f332dae@mail.gmail.com> <20061130232324.GA11621@tigers.local> <91705d080611301535l4a59bd04tbe2f9af6d4147bd5@mail.gmail.com> Message-ID: <20061130235319.GA14587@tigers.local> On Thu, Nov 30, 2006 at 03:35:11PM -0800, Dan Nicholson wrote: > I slogged through the online svn viewer for a little while to figure > this out. It's in gcc_3_0_1_release, but not in gcc-2_95_3 or anything > earlier. Thanks for that. In practical terms, this means any distro with gcc-2.95.x or earlier will be adversely impacted by my proposed changes. Do I really want to impose a host prerequisite of gcc-3.x ? Hmmm.. Dunno. Regards Greg From diy-linux-dev@diy-linux.org Fri Dec 1 01:35:35 2006 From: diy-linux-dev@diy-linux.org (Dan Nicholson) Date: Thu, 30 Nov 2006 16:35:35 -0800 Subject: Fedora Core 6 Host In-Reply-To: <20061130235319.GA14587@tigers.local> References: <20061130221859.GA11259@tigers.local> <91705d080611301453o25274371k761035169f332dae@mail.gmail.com> <20061130232324.GA11621@tigers.local> <91705d080611301535l4a59bd04tbe2f9af6d4147bd5@mail.gmail.com> <20061130235319.GA14587@tigers.local> Message-ID: <91705d080611301635k40595a7exa1f409749374cbb0@mail.gmail.com> On 11/30/06, Greg Schafer wrote: > On Thu, Nov 30, 2006 at 03:35:11PM -0800, Dan Nicholson wrote: > > > I slogged through the online svn viewer for a little while to figure > > this out. It's in gcc_3_0_1_release, but not in gcc-2_95_3 or anything > > earlier. > > Thanks for that. In practical terms, this means any distro with gcc-2.95.x > or earlier will be adversely impacted by my proposed changes. Do I really > want to impose a host prerequisite of gcc-3.x ? Hmmm.. Dunno. You could just add a note that says "If you're using gcc < 3.x, don't add the -B/usr/bin/". Or add a conditional (case `gcc -dumpversion` in ...). You don't get the nice robustness additions, but they were never there before with gcc-2.95.x. Personally, I'd just park the minimum requirement at gcc-3 and call it a day. Most of the people who are going to be bootstrapping their own system from source are probably going to have something a lot more bleeding edge to start off with. How hard is it to get a Live CD, too? But I certainly understand that you want to support the maximum range of hosts possible. -- Dan From diy-linux-dev@diy-linux.org Fri Dec 1 02:33:59 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Fri, 1 Dec 2006 12:33:59 +1100 Subject: Fedora Core 6 Host In-Reply-To: <91705d080611301635k40595a7exa1f409749374cbb0@mail.gmail.com> References: <20061130221859.GA11259@tigers.local> <91705d080611301453o25274371k761035169f332dae@mail.gmail.com> <20061130232324.GA11621@tigers.local> <91705d080611301535l4a59bd04tbe2f9af6d4147bd5@mail.gmail.com> <20061130235319.GA14587@tigers.local> <91705d080611301635k40595a7exa1f409749374cbb0@mail.gmail.com> Message-ID: <20061201013359.GA15254@tigers.local> On Thu, Nov 30, 2006 at 04:35:35PM -0800, Dan Nicholson wrote: > You could just add a note that says "If you're using gcc < 3.x, don't > add the -B/usr/bin/". Or add a conditional (case `gcc -dumpversion` in > ...). Yeah, a conditional is probably the way to go. Athough, -dumpversion may not be the easist to parse as some historical variations exist eg: $ gcc -dumpversion egcs-2.91.66 The actual problem test case can be distilled down to this: $ echo | gcc -B/usr/bin/ -E -o /dev/null - gcc: file path prefix `/usr/bin/' never used Therefore, I could conditionalize it with something like: CC="gcc -B/usr/bin/" if echo | $CC -E -o /dev/null - 2>&1 | grep never > /dev/null; then CC=gcc fi Thus it becomes kinda self documenting :-/ > Personally, I'd just park the minimum requirement at gcc-3 and call it > a day. Probably the sanest option. But then it's just occurred to me that Debian 3.1 was released June '05, which means that just a mere 18 months ago, the "stable" Debian was 3.0 (which uses gcc-2.95.x). > How hard is it to get a Live CD, too? As previously mentioned on this list... From a purists POV, using a Live CD to bootstrap a system is a fundamentally flawed concept ie: the system is tested against a kernel that was not self compiled, a potentially big problem for Glibc. Regards Greg From diy-linux-dev@diy-linux.org Sat Dec 2 02:34:58 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sat, 2 Dec 2006 12:34:58 +1100 Subject: From the bleeding edge... In-Reply-To: <456F3E2C.7020908@infoplatter.com> References: <456F3E2C.7020908@infoplatter.com> Message-ID: <20061202013458.GA2133@tigers.local> On Thu, Nov 30, 2006 at 01:25:16PM -0700, Charles Johnston wrote: > I ran a complete build with very few issues using the following: > > Glibc 2.5 branch snapshot (it hasn't changed since early October) > GCC 4.2 20061127 snapshot > Binutils 2.17.50.0.6 FYI, I'll soon be committing changes for bleeding edge pkgs (even tho' GCC 4.2 doesn't look like releasing anytime soon). > and using Jim Gifford's kernel headers. Ughh. Why would you want do that? No offence to the CLFS guys, but I wouldn't touch those headers with a 10 foot pole. They've obviously put lots of effort in, which is great, but there is a *GIGANTIC* problem with what they're doing. IE: their efforts undermine the momentum of the "headers_install" stuff in the mainline kernel which is the "only way forward" (TM). Part of the problem is the headers_install headers are not that great for some of the second class citizen arches CLFS are targetting. Instead of slugging away on their own, the CLFS guys should be directing their efforts towards getting headers_install working for them. Anything else is insane. There are no excuses for this. No ifs, buts or maybes.. BTW, Glibc apparently doesn't build with headers_install from 2.6.19 due to a reorg of the network headers. This kernel patch fixes it: http://sources.redhat.com/ml/libc-alpha/2006-10/msg00024.html > Aside from that, identical to the current reference build. Thanks for the report. Regards Greg From diy-linux-dev@diy-linux.org Sat Dec 2 04:25:01 2006 From: diy-linux-dev@diy-linux.org (Alberto =?iso-8859-1?q?Trevi=F1o?=) Date: Fri, 1 Dec 2006 20:25:01 -0700 Subject: From the bleeding edge... In-Reply-To: <20061202013458.GA2133@tigers.local> References: <456F3E2C.7020908@infoplatter.com> <20061202013458.GA2133@tigers.local> Message-ID: <200612012025.01468.alberto@byu.edu> On Friday 01 December 2006 18:34, Greg Schafer wrote: > > and using Jim Gifford's kernel headers. > > Ughh. Why would you want do that? No offence to the CLFS guys, but I > wouldn't touch those headers with a 10 foot pole. They've obviously > put lots of effort in, which is great, but there is a *GIGANTIC* > problem with what they're doing. IE: their efforts undermine the > momentum of the "headers_install" stuff in the mainline kernel which > is the "only way forward" (TM). I use the CLFS headers as well. I do it because they work. When 2.6.18=20 came out I tried their headers but they still had issues. At that time=20 I was trying to get a fully stable system all the way up to KDE. Right=20 now I am at that point with 2.6.17, not 2.6.18. =46or me, at least (and I bet I'm not the only one) DIY-Linux, or LFS or=20 in my case, SLIM is both a "perpetual" research project but also a way=20 of life. My servers and workstations at home and at work use SLIM. =20 This means I have to make sure at some point in time, things just work. =20 At those times theory gets replaced by practice and all things that I=20 know I *should* be doing get replaced by whatever works. For me,=20 that's using CLFS headers for 2.6.17 and not using 2.6.18 or 2.6.19. > BTW, Glibc apparently doesn't build with headers_install from 2.6.19 > due to a reorg of the network headers. See? Proves my point. Why would I want to make the precipitated jump=20 to 2.6.19, break the Glibc build, risk losing my data in my IDE drives=20 by using the latest PATA drivers, and make my life miserable when I am=20 trying to get a new box up and running? I would rather go with the=20 tried and tested. We're not all purists like you are, Greg. That's why we come to=20 you. :-) > Regards > Greg =2D-=20 Alberto Trevi=F1o alberto@byu.edu From diy-linux-dev@diy-linux.org Sat Dec 2 19:15:15 2006 From: diy-linux-dev@diy-linux.org (Dan Nicholson) Date: Sat, 2 Dec 2006 10:15:15 -0800 Subject: Zlib beta versions Message-ID: <91705d080612021015m45ee36a4k1eb303a146e52f3d@mail.gmail.com> Hi Greg, I noticed in the Ref Build that you mentioned zlib-1.2.3.1 not being available at that link anymore. The maintainer has made a new area to place these beta releases. http://zlib.net/current/beta/ Feel free to give it a shot. I think 1.2.3.3 will pretty much become the next version. However, it's also the first version where the build will create the static and shared libraries in one shot (and test them both, IIRC), and a few people said it wasn't quite working right. Someone said environment variables weren't being propagated properly. I think there'll probably be another beta version, but there hasn't been any mention lately on the list. I haven't tried it yet, but I'm sure you can figure out the build issues if you're interested. -- Dan From diy-linux-dev@diy-linux.org Sun Dec 3 21:49:30 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Mon, 4 Dec 2006 07:49:30 +1100 Subject: From the bleeding edge... In-Reply-To: <200612012025.01468.alberto@byu.edu> References: <456F3E2C.7020908@infoplatter.com> <20061202013458.GA2133@tigers.local> <200612012025.01468.alberto@byu.edu> Message-ID: <20061203204930.GA10260@tigers.local> On Fri, Dec 01, 2006 at 08:25:01PM -0700, Alberto Trevi=F1o wrote: > I use the CLFS headers as well. I do it because they work. If you define "work" as "hacked beyond belief so that everything compiles= " then, sure. > When 2.6.18 came out I tried their headers but they still had issues. Did you take these issues upstream? This is the only way they'll get fixe= d. Burying your head in the sand helps no one. Post details of the problem somewhere for all to see, here even. A lot of these issues aren't even wi= th the headers. They are due to broken userspace apps who have been abusing kernel headers for years. You are perpetuating the problem by using butchered headers against the wishes of the kernel developers. > At that time I was trying to get a fully stable system all the way up t= o > KDE. Stable system? Then you should have used LLH (with syscalls patch). Do no= t believe the FUD spread by folks like CLFS that LLH are not good enough. > > BTW, Glibc apparently doesn't build with headers_install from 2.6.19 > > due to a reorg of the network headers. >=20 > See? Proves my point. Huh? The CLFS headers had *exactly* the same problem and had to be patche= d! Apparently you're missing the fact that both sets of headers come from th= e same source ie: the kernel tarball. The difference is that the CLFS heade= rs you are using have *already* been "massaged" based on decisions not made = by you, and not by kernel developers. With headers_install, the headers come stright from the horse's mouth (so to speak), not from some Joe Sixpack's (possibly distorted) viewpoint. I could just as easily take the results o= f headers_install, patch them up for known compile issues, tar them all up then release it as DIY headers then everyone would say "Ooooh, look, thes= e DIY headers work".. but that'd be ridiculous. Now do *you* see? > Why would I want to make the precipitated jump to 2.6.19, break the Gli= bc > build, risk losing my data in my IDE drives by using the latest PATA > drivers, and make my life miserable when I am trying to get a new box u= p > and running? Whoa! Dude, take a step back. Running a 2.6.19 kernel has not got nothing= to do with what headers you use to compile your system with. These are distinctly separate matters which lots of folks fail to grasp. Please don= 't lose sight of this. (Incidentally, this lack of understanding is what prompted the CLFS headers project to get off the ground in the first plac= e. That, and impatience). > I would rather go with the tried and tested. Strongly disagree. This is a matter of principle. From what I've seen, th= e CLFS headers constantly react to brokenness by hacking in missing stuff a= nd what not. It's just wrong. Have you looked at the mess that is the CLFS header sanitization script? It's an absolute maintenance nightmare. This logic *belongs* in the kernel source, nowhere else. > We're not all purists like you are, Greg. That's why we come to you. := -) Fair call :-) I guess my biggest stickling point is that the CLFS guys ar= e not kernel developers nor libc developers. Hence they cannot possibly hav= e the required knowledge to produce headers any sane person should trust. Anyhoo, despite my rantings, I don't really care. The CLFS headers will f= ade into insignificance in due course. In the meanwhile, IMHO anyone who uses them is either (a) woefully uninformed (b) of weak moral fibre or (c) has very poor taste :-( But what I do care about is that some folks still do= n't "get" the relationship between running kernel, kernel headers used to compile glibc, and kernel headers in /usr/include for use by userland app= s. Clearly, good documentation on this subject is lacking... Regards Greg From diy-linux-dev@diy-linux.org Sun Dec 3 21:51:15 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Mon, 4 Dec 2006 07:51:15 +1100 Subject: Zlib beta versions In-Reply-To: <91705d080612021015m45ee36a4k1eb303a146e52f3d@mail.gmail.com> References: <91705d080612021015m45ee36a4k1eb303a146e52f3d@mail.gmail.com> Message-ID: <20061203205115.GA10277@tigers.local> On Sat, Dec 02, 2006 at 10:15:15AM -0800, Dan Nicholson wrote: > I noticed in the Ref Build that you mentioned zlib-1.2.3.1 not being > available at that link anymore. The maintainer has made a new area to > place these beta releases. > > http://zlib.net/current/beta/ Awesome. Thanks Dan. I'll update the refbuild doc. Regards Greg From diy-linux-dev@diy-linux.org Sun Dec 3 22:04:53 2006 From: diy-linux-dev@diy-linux.org (Jim Gifford) Date: Sun, 03 Dec 2006 13:04:53 -0800 Subject: From the bleeding edge... In-Reply-To: <200612012025.01468.alberto@byu.edu> References: <456F3E2C.7020908@infoplatter.com> <20061202013458.GA2133@tigers.local> <200612012025.01468.alberto@byu.edu> Message-ID: <45733BF5.2030705@jg555.com> Greg you can say all you want about the CLFS Headers, the bottom line is we take the time to make sure they work will all architectures. No offense to David Woodhouse here, just removing __KERNEL__ from the headers is not enough. You also need to make sure all the programs that rely on them have a chance to build, which install_headers does not do at this point. Not to mention the removal of several headers that are needed for builds, ie page.h. page.h is some unique errors of it's own due to the way it's used on some of the architectures. The bottom line Greg is that we will keep producing headers. Several distros have asked to pick up these headers also. So I must be doing something right, but again Greg everyone has a right to their own opinion. Also before you ask, yes I did offer to help David Woodhouse, but he didn't see the need to respond to me. FYI I used the methods that was layed out by mmauzr, so if that helps your understand why there is such a difference. For those who want to see the difference between my headers and David's, I have a diff posted on my ftp. http://ftp.jg555.com/headers.diff Jim Gifford From diy-linux-dev@diy-linux.org Sun Dec 3 22:18:06 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Mon, 4 Dec 2006 08:18:06 +1100 Subject: From the bleeding edge... In-Reply-To: <45733BF5.2030705@jg555.com> References: <456F3E2C.7020908@infoplatter.com> <20061202013458.GA2133@tigers.local> <200612012025.01468.alberto@byu.edu> <45733BF5.2030705@jg555.com> Message-ID: <20061203211806.GA10404@tigers.local> On Sun, Dec 03, 2006 at 01:04:53PM -0800, Jim Gifford wrote: > Greg you can say all you want about the CLFS Headers, the bottom line is > we take the time to make sure they work will all architectures. As I've already acknowledged, you are targetting 2nd class citizen arches like mips, arm, etc. Work with kernel devs to get these headers sorted. Going off on your own is wrong. If you can't see this, you are selfish beyond all words. > No offense to David Woodhouse here, just removing __KERNEL__ from the > headers is not enough. Jim, gross over simplifications like this don't help. And you're wrong. > You also need to make sure all the programs that rely on them have a > chance to build, which install_headers does not do at this point. Like I said, broken apps. Fix the apps. You are perpetuating brokenness. Fix the apps. > The bottom line Greg is that we will keep producing headers. The bottom line Jim is you are hurting the headers_install effort. Period. Regards Greg From diy-linux-dev@diy-linux.org Mon Dec 4 00:24:06 2006 From: diy-linux-dev@diy-linux.org (Jeremy Huntwork) Date: Sun, 03 Dec 2006 18:24:06 -0500 Subject: From the bleeding edge... In-Reply-To: <20061203204930.GA10260@tigers.local> References: <456F3E2C.7020908@infoplatter.com> <20061202013458.GA2133@tigers.local> <200612012025.01468.alberto@byu.edu> <20061203204930.GA10260@tigers.local> Message-ID: <45735C96.60908@linuxfromscratch.org> Greg Schafer wrote: > Clearly, good documentation on this subject is lacking... That being the case, if you are classifying yourself in the category of those who do "get" how they all work together, why not lay out some documentation yourself, for the benefit of those that don't yet "get" it? I'm writing this in the spirit of someone who could stand to understand the relationships better and would appreciate such documentation by anyone in the know. -- JH From diy-linux-dev@diy-linux.org Mon Dec 4 00:38:50 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Mon, 4 Dec 2006 10:38:50 +1100 Subject: From the bleeding edge... In-Reply-To: <45735C96.60908@linuxfromscratch.org> References: <456F3E2C.7020908@infoplatter.com> <20061202013458.GA2133@tigers.local> <200612012025.01468.alberto@byu.edu> <20061203204930.GA10260@tigers.local> <45735C96.60908@linuxfromscratch.org> Message-ID: <20061203233850.GA15451@tigers.local> On Sun, Dec 03, 2006 at 06:24:06PM -0500, Jeremy Huntwork wrote: > Greg Schafer wrote: > >Clearly, good documentation on this subject is lacking... > > That being the case, if you are classifying yourself in the category of > those who do "get" how they all work together, why not lay out some > documentation yourself, for the benefit of those that don't yet "get" > it? Sure, would love to. But I kinda have my hands full with many other project priorities. Any patches received will be considered for inclusion. Not that I'm any expert.. this is just core stuff that's been hashed out for years. Regards Greg From diy-linux-dev@diy-linux.org Mon Dec 4 01:10:03 2006 From: diy-linux-dev@diy-linux.org (Jim Gifford) Date: Sun, 03 Dec 2006 16:10:03 -0800 Subject: From the bleeding edge... In-Reply-To: <20061203211806.GA10404@tigers.local> References: <456F3E2C.7020908@infoplatter.com> <20061202013458.GA2133@tigers.local> <200612012025.01468.alberto@byu.edu> <45733BF5.2030705@jg555.com> <20061203211806.GA10404@tigers.local> Message-ID: <4573675B.5020503@jg555.com> Greg Schafer wrote: >> No offense to David Woodhouse here, just removing __KERNEL__ from the >> headers is not enough. >> > > Jim, gross over simplifications like this don't help. And you're wrong. > > Greg that's what he does basically. He does make some other minor changes, but it's not enough. >> You also need to make sure all the programs that rely on them have a >> chance to build, which install_headers does not do at this point. >> > > Like I said, broken apps. Fix the apps. You are perpetuating brokenness. Fix > the apps. > I know you like living on the bleeding edge with versions, but most people stick with a version they are familiar with, should we abandon them. I think not. > >> The bottom line Greg is that we will keep producing headers. >> > > The bottom line Jim is you are hurting the headers_install effort. Period. > > I see it as I'm helping the headers_install effort, by showing their short comings. The bottom line being militant on a this issue to get everyone to comply is wrong, there needs to be a progression to allow the change to happen. Once that a fair amount of time has passed, then yes cut them off. From diy-linux-dev@diy-linux.org Mon Dec 4 01:47:35 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Mon, 4 Dec 2006 11:47:35 +1100 Subject: From the bleeding edge... In-Reply-To: <4573675B.5020503@jg555.com> References: <456F3E2C.7020908@infoplatter.com> <20061202013458.GA2133@tigers.local> <200612012025.01468.alberto@byu.edu> <45733BF5.2030705@jg555.com> <20061203211806.GA10404@tigers.local> <4573675B.5020503@jg555.com> Message-ID: <20061204004735.GA16780@tigers.local> On Sun, Dec 03, 2006 at 04:10:03PM -0800, Jim Gifford wrote: > Greg that's what he does basically. He does make some other minor > changes, but it's not enough. Wrong. The kernel devs have intimate knowledge about which headers should be exported and which should not. Armchair generals like you and me have no idea whatsoever. Whenever you add back a header to get some random app to compile, you're going against the kernel devs wishes. Send your issues upstream! How many times do I need to repeat this? > I know you like living on the bleeding edge with versions, but most > people stick with a version they are familiar with, should we abandon > them. I think not. Wrong again. I like *testing* bleeding edge versions and documenting them for folks to use. I personally use stable stuff in production. Why else would I set up the Refbuild with multiple version support? > I see it as I'm helping the headers_install effort, by showing their > short comings. By encouraging folks not to send stuff upstream? Crazy! > The bottom line being militant on a this issue to get everyone to comply > is wrong, there needs to be a progression to allow the change to happen. > Once that a fair amount of time has passed, then yes cut them off. Again, what a load of codswallop. Jim, you have invested lots of time in these headers so you are well placed to communicate with upstream and get the headers working on arches you care about. Regards Greg PS - Sidenote: Jim, your latest changes introducing sysroot on the clfs trunk look completely bogus. The "sysroot" branch appears to get it mostly right. But the trunk changes make no sense at all. Sorry, but I don't care enough to subscribe to the clfs list and gmane won't let me post there either. If anyone's interested, start a new thread here and I'll briefly outline the problems as I perceive them. From diy-linux-dev@diy-linux.org Mon Dec 4 04:11:08 2006 From: diy-linux-dev@diy-linux.org (Alberto =?iso-8859-1?q?Trevi=F1o?=) Date: Sun, 3 Dec 2006 20:11:08 -0700 Subject: From the bleeding edge... In-Reply-To: <20061203204930.GA10260@tigers.local> References: <456F3E2C.7020908@infoplatter.com> <200612012025.01468.alberto@byu.edu> <20061203204930.GA10260@tigers.local> Message-ID: <200612032011.09322.alberto@byu.edu> Didn't mean to open up a can of worms. On Sunday 03 December 2006 13:49, Greg Schafer wrote: > If you define "work" as "hacked beyond belief so that everything > compiles" then, sure. No. On the contrary. Using an "older" version of the software for=20 which a package developer developed for works better than having=20 to "hack" the package to work against future code the developer never=20 envisioned. As you mention yourself, there are better combinations of the toolchain=20 that work better than others. I'm not going to grab Glibc 1.2 and=20 compile it with GCC 4.2 RC X. This is what I meant by "what works." Whatever magic combination gets=20 things to compile and run without errors. Code that doesn't compile=20 won't run without errors. > > When 2.6.18 came out I tried their headers but they still had > > issues. > > Did you take these issues upstream? I didn't but others did. Since I am always a few days behind "latest=20 and greatest" I have found others have had the same problems and found=20 them before I did. > > At that time I was trying to get a fully stable system all the way > > up to KDE. > > Stable system? Then you should have used LLH (with syscalls patch). > Do not believe the FUD spread by folks like CLFS that LLH are not > good enough. Well, it compiled and things have worked without a hitch (typing this=20 message in Kmail). KDE did not compile against 2.6.18 headers. Yes,=20 the problem was reported and it should have been fixed in 2.6.19. > > > BTW, Glibc apparently doesn't build with headers_install from > > > 2.6.19 due to a reorg of the network headers. > > > > See? Proves my point. > > Huh? Trying to compile Glibc with 2.6.19 headers does not work. At this=20 point I have to options: 1. Report the error upstream, wait for a patch (and it might take a few=20 months depending on the type of problem and the maintainers; usually=20 not the case for Kernel, Glibc). 2. Use 2.6.18 or 2.6.17 (in any way, shape or form) or any other that=20 works and later, when time and responsibilities allow, test and use=20 2.6.19. > Whoa! Dude, take a step back. Running a 2.6.19 kernel has not got > nothing to do with what headers you use to compile your system with. I know! My analogy was bad. I can see why you made that comment. =20 That's not what I meant. > IMHO anyone who uses them is either (a) woefully > uninformed (b) of weak moral fibre or (c) has very poor taste :-(=20 I guess I'm all 3. > But what I do care about is that some folks still don't "get" the > relationship between running kernel, kernel headers used to compile > glibc, and kernel headers in /usr/include for use by userland apps. > Clearly, good documentation on this subject is lacking... I think I understand it. Recompiling the kernel doesn't require a full=20 reinstall of Glibc or changing of headers. The point of my comment was that there is a balance in choosing what=20 version of software to make to get a full running, stable system. I am=20 not going to take kernel 2.0.x with Glibc 2.3 and GCC 4.2 beta with=20 module-init-tools 3.2.2! You said so yourself in another post on this=20 thread: that's why you have the ability to compile certain sets of=20 packages as needed. When dealing with the 40+ packages in DIY-Linux,=20 that's fine. Right now I have over 400 packages on my desktop and the=20 balance starts to get trickier and we find ourselves needing to make=20 decisions as we await "official" fixes to propagate. =46or example, there were issues with compiling KDE with 2.6.18 headers. =20 At one "testing" point I decided to install both the 2.6.18 headers and=20 the 2.6.12 headers and switch between them via symlinks. I'm sure=20 you'll agree that is very, very stupid. So did I, so I found another=20 solution: not use 2.6.18 headers and I decided to try the CLFS 2.6.17.x=20 headers. Based on your comments it you think I made a bad decision. =20 I'll have to educate myself and see if my decision needs reconsidering. In the end we are all trying to achieve the same goal: create modern yet=20 stable systems. As we go about it we will all make mistakes and find=20 that practice does not match theory. At those times we'll try to make=20 the best decisions we can. =2D-=20 Alberto Trevi=F1o alberto@byu.edu From diy-linux-dev@diy-linux.org Tue Dec 5 19:38:12 2006 From: diy-linux-dev@diy-linux.org (Bennett Todd) Date: Tue, 5 Dec 2006 18:38:12 +0000 Subject: From the bleeding edge... In-Reply-To: <200612032011.09322.alberto@byu.edu> References: <456F3E2C.7020908@infoplatter.com> <200612012025.01468.alberto@byu.edu> <20061203204930.GA10260@tigers.local> <200612032011.09322.alberto@byu.edu> Message-ID: <20061205183812.GH31157@rahul.net> --enLffk0M6cffIOOh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline By one of these spiffy coincidences I am have been playing with something in this neighborhood this morning. I wanted to build some software a friend wrote (not yet released publicly, sorry); it depended on some stuff in gcc 3.4 not present in gcc-3.3.1 (which is what Bent Linux is currently using). So I tried just doing a build of the current gcc-3.4.6 without any patches, and the first go failed. The error message made it clear that it was a header inconsistency of some sort. Rather than trying to figure it out myself, I pasted the exact error message, surrounded with double-quotes, into google, and the very first hit went to a mailing list message which in turn had a link directly to the gcc.gnu.org/bugzilla query that produced the patch for this precise problem. Google rocks! -Bennett --enLffk0M6cffIOOh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFdbyUHZWg9mCTffwRAiv/AKDG440wftEYv4IAjOuzK73KGdpMBQCguUFU FrsBjNgjYOhJyuitMr8E4zc= =FGMU -----END PGP SIGNATURE----- --enLffk0M6cffIOOh-- From diy-linux-dev@diy-linux.org Tue Dec 5 21:29:37 2006 From: diy-linux-dev@diy-linux.org (Dan Nicholson) Date: Tue, 5 Dec 2006 12:29:37 -0800 Subject: [OT] Google Search Engine Co-op Message-ID: <91705d080612051229l277eadb7o3ffb5acd10dc8833@mail.gmail.com> I already spammed the lfs website list with this, but I wanted to share here, too. You can create a custom google search: http://google.com/coop/cse/overview And include it right into your html. I made one for LFS in like 2 minutes. Look here: http://google.com/coop/cse?cx=012845676306904203607%3Azsvebyymzw8 http://anduin.linuxfromscratch.org/~dnicholson/search/ Here's all the html (they have javascript free, too):
Freaking sweet. -- Dan From diy-linux-dev@diy-linux.org Wed Dec 6 02:03:37 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Wed, 6 Dec 2006 12:03:37 +1100 Subject: GCC / Build Method stuff In-Reply-To: <20061025050051.GA16186@tigers.local> References: <20061025050051.GA16186@tigers.local> Message-ID: <20061206010337.GA28436@tigers.local> On Wed, Oct 25, 2006 at 03:00:51PM +1000, Greg Schafer wrote: > I've been trialling a fix for one of the last remaining "technical > correctness" type bugs in the current build method. There is a small window > early in the chroot phase where GCC does not look at /usr/include (it's > still looking at /temptools/include). As mentioned earlier elsewhere, there > are no adverse effects from this "bug" but I'd rather have it fixed. For > some reason, I always thought there was no way to tweak the preprocessor > search paths via the GCC specs. But of course it's staring me right in the > face. Simply tacking "-I/usr/include" onto the end of the "*cpp:" spec seems > to do the trick. I'll implement this once I've tested all versions/arches. I installed this a while back. But I've only just noticed it generates a copious amount of spurious warnings in the chroot gcc build. This is because /usr/include is not being treated as a system include dir. The solution is to use "-isystem /usr/include" instead. Will fix once testing completes. Regards Greg From diy-linux-dev@diy-linux.org Thu Dec 7 02:45:23 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Thu, 7 Dec 2006 12:45:23 +1100 Subject: From the bleeding edge... In-Reply-To: <200612032011.09322.alberto@byu.edu> References: <456F3E2C.7020908@infoplatter.com> <200612012025.01468.alberto@byu.edu> <20061203204930.GA10260@tigers.local> <200612032011.09322.alberto@byu.edu> Message-ID: <20061207014523.GA19112@tigers.local> On Sun, Dec 03, 2006 at 08:11:08PM -0700, Alberto Trevi=F1o wrote: > Trying to compile Glibc with 2.6.19 headers does not work. At this=20 > point I have to options: Ok, I resisted the urge to start writing a "CLFS headers considered harmf= ul" document.. Instead, I followed my own advice and went straight upstream directly to David Woodhouse. He's been super busy lately but reacted swiiftly by continuing this thread: http://sources.redhat.com/ml/libc-alpha/2006-12/msg00020.html And it seems progress is being made. However, the most important thing to come out of that thread IMHO is that 'headers_install' has the backing of the Red Hat cabal. This is a subtle but significant point in view of the influence said cabal exerts on the GNU toolchain. Beware of cheap imitations! Regards Greg From diy-linux-dev@diy-linux.org Thu Dec 7 03:05:25 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Thu, 7 Dec 2006 13:05:25 +1100 Subject: Bleeding edge changes are in Message-ID: <20061207020525.GA19304@tigers.local> Hi Guys, I've updated the Refbuild with GCC-4.2-pre, Glibc-2.5 and HJL Binutils and thrown in the optional "hash-style-gnu" FC6 specs hack for good measure. The hash-style thing is supposed to improve dynamic linking peformance, but I couldn't measure it accurately. Apparently, dlopen()'d libs (think OpenOffice) will benefit most from this. But it still should generally benefit those who don't prelink. I still need to update the blurb about multiple version support to include the new versions. Am seeing a few math failures in the libc testsuite, but this is often the case when upgrading to a major new GCC. Will investigate this deeper.. Regards Greg From diy-linux-dev@diy-linux.org Sun Dec 10 01:26:52 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sun, 10 Dec 2006 11:26:52 +1100 Subject: From the bleeding edge... In-Reply-To: <20061207014523.GA19112@tigers.local> References: <456F3E2C.7020908@infoplatter.com> <200612012025.01468.alberto@byu.edu> <20061203204930.GA10260@tigers.local> <200612032011.09322.alberto@byu.edu> <20061207014523.GA19112@tigers.local> Message-ID: <20061210002652.GA4808@tigers.local> On Thu, Dec 07, 2006 at 12:45:23PM +1100, Greg Schafer wrote: > On Sun, Dec 03, 2006 at 08:11:08PM -0700, Alberto Trevi=F1o wrote: >=20 > > Trying to compile Glibc with 2.6.19 headers does not work. At this=20 > > point I have to options: >=20 > Ok, I resisted the urge to start writing a "CLFS headers considered har= mful" > document.. Instead, I followed my own advice and went straight upstream > directly to David Woodhouse. He's been super busy lately but reacted > swiiftly by continuing this thread: >=20 > http://sources.redhat.com/ml/libc-alpha/2006-12/msg00020.html >=20 > And it seems progress is being made. Fixed for 2.6.19.1 Regards Greg From diy-linux-dev@diy-linux.org Sun Dec 10 01:37:24 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sun, 10 Dec 2006 11:37:24 +1100 Subject: util-linux-ng Message-ID: <20061210003724.GA4884@tigers.local> Hi Guys, Just noticed these (empty) dirs appeared recently: http://www.kernel.org/pub/linux/utils/util-linux-ng/ http://www.kernel.org/pub/scm/utils/util-linux-ng/ Also noticed there is a new mailing list: http://vger.kernel.org/vger-lists.html#util-linux-ng Anyone know who or what is behind this? The last thing I saw was this on LKML: http://lkml.org/lkml/2006/11/9/262 Util-linux badly needs some love. Current maintainer doesn't respond. Regards Greg From diy-linux-dev@diy-linux.org Mon Dec 11 12:45:48 2006 From: diy-linux-dev@diy-linux.org (Alexander E. Patrakov) Date: Mon, 11 Dec 2006 16:45:48 +0500 Subject: Incompatibility of gcc-4.1.1 build with Make-3.81 Message-ID: <457D44EC.5090709@ums.usu.ru> This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_ums.usu.ru-18959-1165837497-0001-2 Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Hello, Archaic turned my attention to the following piece of GCC Chapter 6 build log in LFS SVN (also present in the LiveCD trunk logs): echo | /lfs-livecd/packages/gcc/gcc-build/./gcc/xgcc -B/lfs-livecd/packages/gcc/gcc-build/./gcc/ -B/usr/i486-pc-linux-gnu/bin/ -B/usr/i486-pc-linux-gnu/lib/ -isystem /usr/i486-pc-linux-gnu/include -isystem /usr/i486-pc-linux-gnu/sys-include -E -dM - | \ sed -n 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p ; \ s/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \ sort -u > tmp-macro_list sed: -e expression #1, char 88: unterminated address regex This bug goes away if I downgrade Make to 3.80. Alternatively, the attached patch (backported from gcc-4_2-branch) has to be applied. -- Alexander E. Patrakov --=_ums.usu.ru-18959-1165837497-0001-2 Content-Type: text/x-patch; name="gcc-4.1.1-newmake-1.patch"; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gcc-4.1.1-newmake-1.patch" Submitted By: Alexander E. Patrakov Date: 2006-12-11 Initial Package Version: 4.1.1 Upstream Status: backported from gcc-4_2-branch Origin: backported from gcc-4_2-branch Description: Fixes incompatibility with Make-3.81, that would result in the following messages in the build log: echo | /lfs-livecd/packages/gcc/gcc-build/./gcc/xgcc -B/lfs-livecd/packages/gcc/gcc-build/./gcc/ -B/usr/i486-pc-linux-gnu/bin/ -B/usr/i486-pc-linux-gnu/lib/ -isystem /usr/i486-pc-linux-gnu/include -isystem /usr/i486-pc-linux-gnu/sys-include -E -dM - | \ sed -n 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p ; \ s/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \ sort -u > tmp-macro_list sed: -e expression #1, char 88: unterminated address regex --- gcc-4.1.1/gcc/Makefile.in +++ gcc-4.1.1/gcc/Makefile.in @@ -3146,8 +3209,8 @@ macro_list: s-macro_list; @true s-macro_list : $(GCC_PASSES) echo | $(GCC_FOR_TARGET) -E -dM - | \ - sed -n 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p ; \ - s/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \ + sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \ + -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \ sort -u > tmp-macro_list $(SHELL) $(srcdir)/../move-if-change tmp-macro_list macro_list $(STAMP) s-macro_list --=_ums.usu.ru-18959-1165837497-0001-2-- From diy-linux-dev@diy-linux.org Mon Dec 11 21:42:39 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Tue, 12 Dec 2006 07:42:39 +1100 Subject: GNU fdisk (was Re: util-linux-ng) In-Reply-To: <20061210003724.GA4884@tigers.local> References: <20061210003724.GA4884@tigers.local> Message-ID: <20061211204238.GA7468@tigers.local> On Sun, Dec 10, 2006 at 11:37:24AM +1100, Greg Schafer wrote: > Just noticed these (empty) dirs appeared recently: > > http://www.kernel.org/pub/linux/utils/util-linux-ng/ > http://www.kernel.org/pub/scm/utils/util-linux-ng/ And on the heels of this arrives GNU fdisk! http://www.gnu.org/software/fdisk/ Looks like it's based on libparted.. Regards Greg From diy-linux-dev@diy-linux.org Tue Dec 12 00:50:09 2006 From: diy-linux-dev@diy-linux.org (Alberto =?iso-8859-1?q?Trevi=F1o?=) Date: Mon, 11 Dec 2006 16:50:09 -0700 Subject: GNU fdisk (was Re: util-linux-ng) In-Reply-To: <20061211204238.GA7468@tigers.local> References: <20061210003724.GA4884@tigers.local> <20061211204238.GA7468@tigers.local> Message-ID: <200612111650.09985.alberto@byu.edu> On Monday 11 December 2006 13:42, Greg Schafer wrote: > And on the heels of this arrives GNU fdisk! Is it going to become part of the base install or at least "optional"? =2D-=20 Alberto Trevi=F1o alberto@byu.edu From diy-linux-dev@diy-linux.org Tue Dec 12 01:09:20 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Tue, 12 Dec 2006 11:09:20 +1100 Subject: GNU fdisk (was Re: util-linux-ng) In-Reply-To: <200612111650.09985.alberto@byu.edu> References: <20061210003724.GA4884@tigers.local> <20061211204238.GA7468@tigers.local> <200612111650.09985.alberto@byu.edu> Message-ID: <20061212000920.GA10695@tigers.local> On Mon, Dec 11, 2006 at 04:50:09PM -0700, Alberto Trevi=F1o wrote: > On Monday 11 December 2006 13:42, Greg Schafer wrote: > > And on the heels of this arrives GNU fdisk! >=20 > Is it going to become part of the base install or at least "optional"? Possibly, but only time will tell I s'pose. At this stage, I just wanted = to get the word out that there are (at least partial) alternatives to util-linux. I'm hopeful util-linux-ng will eventually come to the party. Regards Greg From diy-linux-dev@diy-linux.org Thu Dec 14 12:59:18 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Thu, 14 Dec 2006 22:59:18 +1100 Subject: coreutils-6.3 and fakeroot (was Re: bash-3.2 and fakeroot) In-Reply-To: <1163587314.8380.38.camel@mjollnir.borkware.net> References: <20061020012423.GA705@tigers.local> <1163587314.8380.38.camel@mjollnir.borkware.net> Message-ID: <20061214115918.GA28644@tigers.local> On Wed, Nov 15, 2006 at 11:41:54AM +0100, Mark Rosenstand wrote: > On Fri, 2006-10-20 at 11:24 +1000, Greg Schafer wrote: > > Fakeroot is very much a Debian thing. AFAICT Debian is still on glibc-2.3.6 > > and coreutils-5.97. They have uploaded glibc-2.{4,5} to "experimental" but > > they probably haven't hit the fakeroot issues yet. As soon as they are made > > aware of the problem I'm sure they'll add the required support to fakeroot. > > Let's hope they do. And let's try to figure out a less hacky way to > create packages, so we won't get stucked like this again. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402688 Note that it's "unfinished".. Regards Greg From diy-linux-dev@diy-linux.org Fri Dec 15 01:21:41 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Fri, 15 Dec 2006 11:21:41 +1100 Subject: Incompatibility of gcc-4.1.1 build with Make-3.81 In-Reply-To: <457D44EC.5090709@ums.usu.ru> References: <457D44EC.5090709@ums.usu.ru> Message-ID: <20061215002141.GA10372@tigers.local> On Mon, Dec 11, 2006 at 04:45:48PM +0500, Alexander E. Patrakov wrote: > Archaic turned my attention to the following piece of GCC Chapter 6 > build log in LFS SVN (also present in the LiveCD trunk logs): > > echo | /lfs-livecd/packages/gcc/gcc-build/./gcc/xgcc > -B/lfs-livecd/packages/gcc/gcc-build/./gcc/ > -B/usr/i486-pc-linux-gnu/bin/ -B/usr/i486-pc-linux-gnu/lib/ -isystem > /usr/i486-pc-linux-gnu/include -isystem > /usr/i486-pc-linux-gnu/sys-include -E -dM - | \ > sed -n 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p ; \ > s/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \ > sort -u > tmp-macro_list > sed: -e expression #1, char 88: unterminated address regex > > This bug goes away if I downgrade Make to 3.80. Alternatively, the > attached patch (backported from gcc-4_2-branch) has to be applied. Thanks for the report. But please note the bug is completely harmless from our POV so I will not be fixing it. This bit of Makefile affects creation of the file `macro_list' which is used in the fixincludes process. And seeing as we disable fixincludes.. there is nil effect on the installed compiler. Regards Greg From diy-linux-dev@diy-linux.org Fri Dec 15 01:33:59 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Fri, 15 Dec 2006 11:33:59 +1100 Subject: Incompatibility of gcc-4.1.1 build with Make-3.81 In-Reply-To: <20061215002141.GA10372@tigers.local> References: <457D44EC.5090709@ums.usu.ru> <20061215002141.GA10372@tigers.local> Message-ID: <20061215003359.GA10427@tigers.local> On Fri, Dec 15, 2006 at 11:21:41AM +1100, Greg Schafer wrote: > This bit of Makefile affects creation of the file `macro_list' which is used > in the fixincludes process. And seeing as we disable fixincludes.. there is > nil effect on the installed compiler. Actually, I tell a lie. With the bugfix, this installed file: /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/install-tools/macro_list contains the following instead of being zero byte in size: i386 linux unix but as I said, fixincludes is disabled during the gcc build and I don't know of anyone who has ever used the "installed" copy of fixincludes so I'm sticking with the view that the bug is harmless. (The fix is installed on the branches so we'll pick it up if/when 4.0.4 or 4.1.2 arrives). Regards Greg From diy-linux-dev@diy-linux.org Fri Dec 15 04:29:32 2006 From: diy-linux-dev@diy-linux.org (Alexander E. Patrakov) Date: Fri, 15 Dec 2006 08:29:32 +0500 Subject: Another gcc bug Message-ID: <4582169C.6060908@ums.usu.ru> This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_ums.usu.ru-26445-1166153312-0001-2 Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Hello, if one builds anything with gcc-4.1.1 with -Os -ffast-math flags, the resulting program will segfault on modern CPUs. This is an issue for the LiveCD, because it builds everything with -Os, and procps adds -ffast-math (thus, ps segfaults). Upstream has fixed this, please apply the attached patch. P.S. I think it is a good idea to search gcc bugzilla for "fixed critical bugs targetted at gcc-4.1.2" and consider them as well. -- Alexander E. Patrakov --=_ums.usu.ru-26445-1166153312-0001-2 Content-Type: text/x-patch; name="gcc-4.1.1-pr13685-1.patch"; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gcc-4.1.1-pr13685-1.patch" Submitted By: Alexander E. Patrakov Date: 2006-12-11 Initial Package Version: 4.1.1 Upstream Status: backport Origin: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621 Description: Fix crash of programs compiled with -Os -ffast-math (affects procps on the LiveCD) --- gcc-4.1.1/gcc/config/i386/i386.c +++ gcc-4.1.1/gcc/config/i386/i386.c @@ -1502,12 +1502,10 @@ } /* Validate -mpreferred-stack-boundary= value, or provide default. - The default of 128 bits is for Pentium III's SSE __m128, but we - don't want additional code to keep the stack aligned when - optimizing for code size. */ - ix86_preferred_stack_boundary = (optimize_size - ? TARGET_64BIT ? 128 : 32 - : 128); + The default of 128 bits is for Pentium III's SSE __m128, We can't + change it because of optimize_size. Otherwise, we can't mix object + files compiled with -Os and -On. */ + ix86_preferred_stack_boundary = 128; if (ix86_preferred_stack_boundary_string) { i = atoi (ix86_preferred_stack_boundary_string); --=_ums.usu.ru-26445-1166153312-0001-2-- From diy-linux-dev@diy-linux.org Fri Dec 15 06:05:25 2006 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Fri, 15 Dec 2006 16:05:25 +1100 Subject: Another gcc bug In-Reply-To: <4582169C.6060908@ums.usu.ru> References: <4582169C.6060908@ums.usu.ru> Message-ID: <20061215050525.GA15329@tigers.local> On Fri, Dec 15, 2006 at 08:29:32AM +0500, Alexander E. Patrakov wrote: > if one builds anything with gcc-4.1.1 with -Os -ffast-math flags, the > resulting program will segfault on modern CPUs. Thanks for the report. But anyone using those flags ought to know what they're doing and accept the consequences. BTW, according to the PR, this bug is ancient and affects 3.2.3 3.3.6 3.4.6 4.0.3 4.1.0 4.2.0. Therefore IMHO your report is bordering on unnecessary alarmism. > This is an issue for the > LiveCD, because it builds everything with -Os, and procps adds > -ffast-math (thus, ps segfaults). Upstream has fixed this, please apply > the attached patch. Building everything with -Os is risky IMHO. I wouldn't do it. I won't be applying this patch because there are loads of quirky corner cases like this. > P.S. I think it is a good idea to search gcc bugzilla for "fixed > critical bugs targetted at gcc-4.1.2" and consider them as well. I disagree. 4.1.1 works pretty well in general. Folks who want maximum bug fixes should consider using a 4.1.2 snapshot instead. Regards Greg From diy-linux-dev@diy-linux.org Fri Dec 15 06:33:16 2006 From: diy-linux-dev@diy-linux.org (Jeremy Huntwork) Date: Thu, 14 Dec 2006 22:33:16 -0700 Subject: Another gcc bug In-Reply-To: <20061215050525.GA15329@tigers.local> References: <4582169C.6060908@ums.usu.ru> <20061215050525.GA15329@tigers.local> Message-ID: <20061215053316.GA1759@linuxfromscratch.org> On Fri, Dec 15, 2006 at 04:05:25PM +1100, Greg Schafer wrote: > Thanks for the report. But anyone using those flags ought to know what > they're doing and accept the consequences. BTW, according to the PR, this > bug is ancient and affects 3.2.3 3.3.6 3.4.6 4.0.3 4.1.0 4.2.0. Therefore > IMHO your report is bordering on unnecessary alarmism. Except that this behavior is only now exhibiting itself with gcc-4.1.1 on the LiveCD builds. AFAIK, nothing has changed as far as compiler flags in our build scripts, but with the bump to gcc-4.1.1 and procps-3.2.7, ps segfaults. procps-3.2.6 shows the same internal compile flags as 3.2.7, '-fno-common -ffast-math', so it seems that something has changed with gcc-4.1.1. I've seen the bug reports upstream, so I know what you're saying about it being an old bug, but it definitely wasn't being tickled before. I'm not disagreeing with your point - those who want to change optimization settings should be prepared to deal with unexpected results. Mostly, I just wanted to offer some extra background info. Still, it is a recognized bug in gcc and IMO, once that's acknowledged, to me it only makes sense to apply the fix, no matter how likely it is that a reader/user would be encountering the bug. -- JH From diy-linux-dev@diy-linux.org Fri Dec 15 16:10:26 2006 From: diy-linux-dev@diy-linux.org (Alberto =?iso-8859-1?q?Trevi=F1o?=) Date: Fri, 15 Dec 2006 08:10:26 -0700 Subject: Another gcc bug In-Reply-To: <20061215050525.GA15329@tigers.local> References: <4582169C.6060908@ums.usu.ru> <20061215050525.GA15329@tigers.local> Message-ID: <200612150810.27070.alberto@byu.edu> On Thursday 14 December 2006 22:05, Greg Schafer wrote: > this bug is ancient and affects 3.2.3 3.3.6 3.4.6 4.0.3 4.1.0 > 4.2.0. Therefore IMHO your report is bordering on unnecessary > alarmism. I reported on this problem on this list several months ago. If I=20 recall, the problem comes from compiling GCC with -Os. If you compile=20 GCC with -O2 and then compile procps with -Os it still works. And yes, this problem is well known. The latest procps triggered it. =20 My records show procps was last updated late June early July. I'm=20 surprised they barely ran into it. =2D-=20 Alberto Trevi=F1o alberto@byu.edu CID Testing Center Brigham Young University From diy-linux-dev@diy-linux.org Fri Dec 15 17:14:36 2006 From: diy-linux-dev@diy-linux.org (Alexander E. Patrakov) Date: Fri, 15 Dec 2006 21:14:36 +0500 Subject: Another gcc bug In-Reply-To: <20061215050525.GA15329@tigers.local> References: <4582169C.6060908@ums.usu.ru> <20061215050525.GA15329@tigers.local> Message-ID: <4582C9EC.2060508@ums.usu.ru> Greg Schafer wrote: > Folks who want maximum bug fixes should consider using a 4.1.2 snapshot instead. > This probably makes sense - look what Debian is doing. I will certainly try that. -- Alexander E. Patrakov From diy-linux-dev@diy-linux.org Sun Dec 17 19:20:34 2006 From: diy-linux-dev@diy-linux.org (Bennett Todd) Date: Sun, 17 Dec 2006 18:20:34 +0000 Subject: bug in cpio 2.7 (with fix included) In-Reply-To: <20061115024047.GA18364@tigers.local> References: <4557C2D3.2010200@infoplatter.com> <20061114051733.GA31390@tigers.local> <20061115024047.GA18364@tigers.local> Message-ID: <20061217182034.GC15708@rahul.net> --k4f25fnPtRuIRUb3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 2006-11-15T02:40:47 Greg Schafer: > Bennett, if you're reading this, I notice you've already updated Bent to > cpio-2.7. You might want to reconsider :-/ Thanks! I backed down to 2.6. Then a kind new friend named Rien Bartelings called my attention to the fact that cpio wasn't being kind to the busybox bpm. 2.6 didn't preserve hard links properly. Yuck. So I switched the busybox bpm to use symlinks instead, and voila, I discovered GNU cpio 2.6 forcibly dereferenced the symlinks. I've upgraded Bent Linux to 2.4.2. -Bennett --k4f25fnPtRuIRUb3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFhYpyHZWg9mCTffwRAoFKAJ9TpQ7uTU5U89nAoPxM1kt/lTRb6gCfYFD2 HnvNSGKTEaMvtd9tNgBCO9o= =JEQl -----END PGP SIGNATURE----- --k4f25fnPtRuIRUb3--