From diy-linux-dev@diy-linux.org Tue Apr 3 13:22:13 2007 From: diy-linux-dev@diy-linux.org (Jeremy Byron) Date: Tue, 03 Apr 2007 06:22:13 -0700 Subject: [Eh?] Ref Build - 3.5 GCC Pass 1 (3.4.6 through 4.2-pre) Message-ID: <46125505.2030108@shaw.ca> Greg, I've been browsing through your build script and comparing your reference build to LFS, which I've been using since v3-ish but it's time to move on, and noticed what looks like an inconsistency/typeo in '3.5 GCC Pass 1 (3.4.6 through 4.2-pre)'. You note, as in Binutils Pass 1, no static linking of GCC but you are passing --disable-shared to configure (contrary to LFS and to your note unless I just don't understand exactly what --disable-shared does). The second pass has --enable-shared, as I would expect. LFS notes that --enable-shared 'allows the building of libgcc_s.so.1 and libgcc_eh.a' needed by Glibc. You also note that libgcc_eh.a is needed for Glibc when you use --disable-shared, and you work around it with a simlink. The mailing list post you link to seems to be based on the assumption that you need to use '--disable-shared', but you don't say why so that wasn't much help - unless its a cross compile related use which afaik doesn't apply to the reference build. This seems inconsistent to me, and so I'm rather confused. Assuming --disable-shared builds GCC statically (and according to gcc.gnu.org/install/configure.html, its used 'to build only static libraries'), doesn't the need for your symlink go away with --enable-shared? And it wouldn't be built statically contrary to your note. I'd appreciate any thoughts you might have on this to clear things up some; confusion hurts the head. :) Anyhow, excellent job on the ref build and your script.. your notes and rationale links are great. After running your script through a successful build, I'm in tweak mode and your script in its current state makes it really easy. Much thanks! Regards, Jeremy. From diy-linux-dev@diy-linux.org Fri Apr 6 00:02:47 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Fri, 6 Apr 2007 10:02:47 +1000 Subject: [Eh?] Ref Build - 3.5 GCC Pass 1 (3.4.6 through 4.2-pre) In-Reply-To: <46125505.2030108@shaw.ca> References: <46125505.2030108@shaw.ca> Message-ID: <20070406000247.GA24715@eyo32.local> On Tue, Apr 03, 2007 at 06:22:13AM -0700, Jeremy Byron wrote: > You note, as in Binutils Pass 1, no static linking of GCC but you are > passing --disable-shared to configure (contrary to LFS and to your note > unless I just don't understand exactly what --disable-shared does). The > second pass has --enable-shared, as I would expect. > > LFS notes that --enable-shared 'allows the building of libgcc_s.so.1 and > libgcc_eh.a' needed by Glibc. > > You also note that libgcc_eh.a is needed for Glibc when you use > --disable-shared, and you work around it with a simlink. The mailing > list post you link to seems to be based on the assumption that you need > to use '--disable-shared', but you don't say why so that wasn't much > help - unless its a cross compile related use which afaik doesn't apply > to the reference build. > > This seems inconsistent to me, and so I'm rather confused. Yes, I think you are :-) Passing `--disable-shared' to GCC and linking executables statically are completely separate issues. Static linking is all about making self-contained binaries ie: all the needed libc code is included in the binaries themselves meaning they will theoretically run without a libc being available. (sidenote: not quite true in reality). The comment about LFS linking statically is outdated. LFS used to statically link the Pass 1's of Binutils and GCC, but some time ago they followed the the DIY lead and stopped doing it. I pass `--disable-shared' to GCC Pass 1 because it's simply the sanest thing to do when bootstrapping a new toolchain. Cross compilation techniques do same. IMHO it results in a more robust build method (less chance of things going wrong). The only wart is the Glibc -lgcc_eh thing. But that's because the Glibc devs don't really care about (nor should they) minority groups who (a) port to new platforms or (b) bootstrap like us. Regards Greg From diy-linux-dev@diy-linux.org Fri Apr 6 00:27:36 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Fri, 6 Apr 2007 10:27:36 +1000 Subject: Simplify grep for sysklogd and util-linux In-Reply-To: <4601195D.4010401@neptune-one.net> References: <4601195D.4010401@neptune-one.net> Message-ID: <20070406002736.GA24845@eyo32.local> On Wed, Mar 21, 2007 at 11:39:09AM +0000, Andrew Fyfe wrote: > Just a small tweak to the grep in sysklogd and util-linux > > before: > if grep LIBC /usr/include/linux/version.h >/dev/null 2>&1; then > after: > if grep -q LIBC /usr/include/linux/version.h; then Heh, I'd forgotten about grep -q. Dunno how portable it is, not that it really matters :-/ I'll use this if it tests out ok. Thanks. Regards Greg PS - Now I remember something about this. Using grep -q does not always work like you'd expect in some bizarre circumstances. For example see here: http://sourceware.org/ml/libc-alpha/2004-01/msg00059.html From diy-linux-dev@diy-linux.org Fri Apr 6 00:53:14 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Fri, 6 Apr 2007 10:53:14 +1000 Subject: 1.5. Build Notes In-Reply-To: <1174598944.3391.28.camel@dragon23dragon.example.org> References: <1174598944.3391.28.camel@dragon23dragon.example.org> Message-ID: <20070406005314.GA25651@eyo32.local> On Fri, Mar 23, 2007 at 07:59:04AM +1030, linux23dragon wrote: > Section 1.5 (Build Notes) in the Reference build is talking about how > rock solid the system is or should be. Would it be worth adding a note > about stable kernels as well? Hmm, I don't think so. It already says "Latest 2.6.X kernel". The Refbuild is focused mainly on toolchain / libc / userland and doesn't mention much when it comes to kernels. I'd expect most folks here have been compiling their own kernels for years, even long before they started building their own distro. Maybe it's wrong but I just take it for granted folks know their kernel stuff. But thanks for the suggestion anyway. Sidenote: One of the things I love most about Linux is the complete separation of Kernel and Userland. They are completely different beasts. eg: compile each with a different toolchain, no problem. Regards Greg From diy-linux-dev@diy-linux.org Fri Apr 6 01:02:03 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Fri, 6 Apr 2007 11:02:03 +1000 Subject: chroot coreutils test error In-Reply-To: <20070327225658.GA3845@hyper> References: <20070322181056.GD2225@hyper> <20070322231322.GA24301@hyper> <20070324052255.GF24301@hyper> <20070327225658.GA3845@hyper> Message-ID: <20070406010203.GA28161@eyo32.local> On Tue, Mar 27, 2007 at 04:56:58PM -0600, Ken Dyke wrote: > On Fri, Mar 23, 2007 at 11:22:55PM -0600, Ken Dyke (ken_i_m@elegantinnovations.net) wrote: > > On Thu, Mar 22, 2007 at 05:13:22PM -0600, Ken Dyke (ken_i_m@elegantinnovations.net) wrote: > > > Still bombs at the same place in chroot coreutils test. > > Yep, still beating on this... > > Attached is an strace file that shows where /bin/bash bombs. > > Just a reminder that /bin/bash is a symlink to /temptools/bin/bash which > was built in the temptools stage. Ken, sorry for late reply. Don't know what to think of this because it works for me and most other folks I believe. But having said that, the Coreutils testsuite can be very picky if you are doing something slightly different. Have you tried running the test in question verbosely as per the instructions in the Coreutils README ? Regards Greg From diy-linux-dev@diy-linux.org Fri Apr 6 02:40:30 2007 From: diy-linux-dev@diy-linux.org (Jeremy Byron) Date: Thu, 05 Apr 2007 19:40:30 -0700 Subject: [Eh?] Ref Build - 3.5 GCC Pass 1 (3.4.6 through 4.2-pre) In-Reply-To: <20070406000247.GA24715@eyo32.local> References: <46125505.2030108@shaw.ca> <20070406000247.GA24715@eyo32.local> Message-ID: <4615B31E.9060309@shaw.ca> Greg Schafer wrote: > Yes, I think you are :-) Passing `--disable-shared' to GCC and linking > executables statically are completely separate issues. No shared libs and therefore static libs, but completely separate issues? I trust you can see my confusion.. :) If it's not suppressing the generation of dynamic libs while building against existing dynamic/static libs (and thus creating static libs), is it instead only disabling the use of existing dynamic libs when linking (and thus creating static binaries/libs from existing static libs)? Sigh. > Static linking is all > about making self-contained binaries ie: all the needed libc code is > included in the binaries themselves meaning they will theoretically run > without a libc being available. (sidenote: not quite true in reality). I understand the general idea of code getting packed into binary so, for example, you don't have to ship libs it was built against for it to work on a system without those libs.. Of course, I'm certainly not intimately familiar with all the detail regarding how the process works. > The comment about LFS linking statically is outdated. LFS used to statically > link the Pass 1's of Binutils and GCC, but some time ago they followed the > the DIY lead and stopped doing it. If they followed DIY's lead at one point, they're deviating again with --enable-shared - which is only adding to my confusion. Of course, I've noticed that the LFS devs have a tendency to take the easiest path on occasion rather than the 'right' path, whatever that is. > I pass `--disable-shared' to GCC Pass 1 because it's simply the sanest thing > to do when bootstrapping a new toolchain. I'll take your word for it - you know a hell of a lot more of this stuff than I - but it'd be nice to understand it more thoroughly. What specifically breaks if you use --enable-shared in this pass? Or, rather than wasting your time trying to explain, do you know of any decent related reference(s) off hand? > Cross compilation techniques do > same. IMHO it results in a more robust build method (less chance of things > going wrong). I notice that CLFS does indeed use --disable-shared contrary to LFS. But they're calling it a static build whereas your notes suggest that you're not building statically. If it's as simple as that you are actually building statically, then inconsistency fixed - minus the possible source of failure thing you didn't cite for building statically. Just found http://www.osdev.org/wiki/GCC_Cross-Compiler that, along with all kinds of other stuff, says: "The --disable-shared option This is an option to the GCC configure process that you might or might not use. It's a bit tricky... with --disable-shared... ...every single executable in your cross-compiler environment will be statically linked, which makes them huge. On the other hand, you can move around those executables, as there are no dependencies (which is what you want in step 4 above, to "bootstrap" your first native compiler). However, if you compiled any of the libraries that are linked in with a more advanced -march, the resulting executable is going to be only for that arch or better. This is usually no problem - unless you're doing a Canadian Cross where you might want to put the executable on a slower (less-featured) machine. Bad luck... without --disable-shared... ...the executables will use dynamic linking, and will be much smaller. Now comes the tricky part: Not only the system libraries are dynamically linked, but also those implementing generic functionality of the cross-compilation environment. This is done by hard-coding the library paths into the executables... meaning that you can not move them to another directory. This is usually not necessary - unless you're doing a Canadian Cross where you might want to build the executables in a directory different from the one you want to install them in (e.g. due to access limitations on the build machine). Bad luck... " So again, my interpretation is that you're really building everything statically with --disable-shared, even though you note that static builds are a potential source of failure. Unless this page is simply wrong or I'm misinterpreting.. (I question everything in case you haven't gathered that yet.. ) > The only wart is the Glibc -lgcc_eh thing. But that's because > the Glibc devs don't really care about (nor should they) minority groups who > (a) port to new platforms or (b) bootstrap like us. This sounds like as good a reason as any to use --enable-shared provided that the toolchain doesn't break. IMO, robustness is only a good reason as far as obtaining a just-working model in the presence of things that would cause awkward workarounds. In otherwords, if --enable-shared works properly for the intended purpose (at least currently and however unrobust it may be), why force yourself into workarounds when fixes can't/won't be implemented upstream? If in the future, --enable-shared were to break something then the workaround would be necessary and the argument for robustness satisfied. I think I'm just missing the reason for using --disable-shared. That --disable-shared is the most sane way to bootstrap a toolchain isn't a good reason to use it (at least not one for anyone capable of thought). Why is it the most sane way? What failures prompted the idea that it is the most sane way? Etc.. ? Perhaps with the above, you can better see where my source of confusion lies. I suppose I should just run through two builds and compare the differences resulting from the use of --enable-shared or --disable-shared - but I assume you've done this and have a good reason for one over the other that I'm just not seeing. I'm not trying to poke at you or criticize - please don't take this as such - I just want to understand what I'm doing. When I come upon something that seems inconsistent I have this crazy need to resolve it - comes with being a(n) (ignorant) geek, I think. Vacuous statements just make me nitpick all the harder because they suggest 'in theory, in my opinion' rather than 'in practice, according to my test results' and don't give any insight beyond FBBG - what I seek is the insight to write the book in the first place. Anyhow, much thanks for for your time. I really do appreciate your insight. Jeremy. From diy-linux-dev@diy-linux.org Fri Apr 6 23:01:55 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sat, 7 Apr 2007 09:01:55 +1000 Subject: [Eh?] Ref Build - 3.5 GCC Pass 1 (3.4.6 through 4.2-pre) In-Reply-To: <4615B31E.9060309@shaw.ca> References: <46125505.2030108@shaw.ca> <20070406000247.GA24715@eyo32.local> <4615B31E.9060309@shaw.ca> Message-ID: <20070406230155.GA6872@eyo32.local> On Thu, Apr 05, 2007 at 07:40:30PM -0700, Jeremy Byron wrote: > No shared libs and therefore static libs, but completely separate > issues? I trust you can see my confusion.. :) Let me try putting it another way.. When you build GCC Pass 1 with `--disable-shared', the GCC *binaries* are *NOT* linked statically. They are created as dynamically linked binaries. Try running `file /temptools/bin/gcc' on the pass 1 GCC to see for yourself. If one wanted to build a GCC where the *GCC binaries themselves* are statically linked (as LFS used to do) one would have to build GCC with something like: make BOOT_LDFLAGS="-static" bootstrap I repeat, linking binaries statically has got nothing to do with whether you configured GCC with `--disable-shared' or `--enable-shared'. Now, the GCC website is correct in saying "Use --disable-shared to build only static libraries" but please note, it is referring only to GCC's own libraries! libgcc etc. You can still *produce* dynamically linked binaries with a GCC that was configured with `--disable-shared'! Again, try it out for yourself. > I'll take your word for it - you know a hell of a lot more of this stuff > than I - but it'd be nice to understand it more thoroughly. What > specifically breaks if you use --enable-shared in this pass? Well, the build will fail if the host is an older distro. See here for eg: http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055262.html > I notice that CLFS does indeed use --disable-shared contrary to LFS. > But they're calling it a static build Badly worded by CLFS IMHO. > whereas your notes suggest that you're not building statically. No! I say not *linking* statically. > Just found http://www.osdev.org/wiki/GCC_Cross-Compiler that, along with > all kinds of other stuff, says: > with --disable-shared... > > ...every single executable in your cross-compiler environment will be > statically linked, which makes them huge. WRONG WRONG WRONG! Wow, What a load of rubbish! It's no wonder you're confused when this sort of crap exists. Again, you can debunk these falsehoods in seconds by performing some simple tests of your own which I encourage you to do. It's the best way to learn. > Anyhow, much thanks for for your time. I really do appreciate your insight. No probs. Good luck. Regards Greg From diy-linux-dev@diy-linux.org Tue Apr 10 08:55:46 2007 From: diy-linux-dev@diy-linux.org (Jeremy Byron) Date: Tue, 10 Apr 2007 01:55:46 -0700 Subject: [Eh?] Ref Build - 3.5 GCC Pass 1 (3.4.6 through 4.2-pre) In-Reply-To: <20070406230155.GA6872@eyo32.local> References: <46125505.2030108@shaw.ca> <20070406000247.GA24715@eyo32.local> <4615B31E.9060309@shaw.ca> <20070406230155.GA6872@eyo32.local> Message-ID: <461B5112.7020506@shaw.ca> Greg Schafer wrote: > When you build GCC Pass 1 with `--disable-shared', the GCC *binaries* are > *NOT* linked statically. They are created as dynamically linked binaries. > Try running `file /temptools/bin/gcc' on the pass 1 GCC to see for yourself. I follow you now.. I built it both ways and poked around the resulting binaries/libs with file, readelf, and ldd. I should have known how to use these programs a long time ago. Found a brief doc describing static, shared, and DL libraries that helped some too. > If one wanted to build a GCC where the *GCC binaries themselves* are > statically linked (as LFS used to do) one would have to build GCC with > something like: > > make BOOT_LDFLAGS="-static" bootstrap I recall that line from a while back now that you mention it. That helps. > Well, the build will fail if the host is an older distro. See here for eg: > > http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055262.html RH7.0 is near seven years old. I'm impressed that you're willing and able to support such old hosts and get a clean build from them - a lot changes in that much time. I did some reading on RH7 for the hell of it. Apparently they shipped with a development version of GCC (2.96) that was binary compatible with neither GCC 2.95.x nor the forthcoming GCC 3.x. I imagine that the 'binary compatible' issue is probably irrelevant given that we're building from source and linking against the temptools as they're built. But given RH's gimpy toolchain decisions and you and LFS not using GCC 2.96 I'm not surprised that there would be problems building on a RH7 host. GCC issued an announcement criticizing the usage of GCC 2.96 in a distro (http://gcc.gnu.org/ml/gcc-announce/2000/msg00003.html) and a quick search will show a myriad of gripes about how terribly buggy RH7.0 was. I can understand the need to support RH7 despite this given its popularity so long as it was in mainstream use, but at this point I think it's time to let it pass; should someone actually try your Refbuild with RH7 or similarly gimped legacy host (s)he could always be pointed to the workaround in an archive somewhere. In any case, since I'm working from a recent LFS build, I guess I'll just use --enable-shared in my own builds until/unless I see that something breaks and avoid the simlink workaround. > WRONG WRONG WRONG! Wow, What a load of rubbish! It's no wonder you're > confused when this sort of crap exists. Google's both a blessing and a curse. I try to cross-reference everything I read but when more than one trusted (or apparently trustworthy) source conflicts matters get prickly. Thanks for the heads up. -- At least now I have a much clearer understanding of what's going on and how to poke around the files. Long way to go yet, but I'll get there. Thanks again for your help and pointing out the nonsense (both mine and others'). Regards, Jeremy. From diy-linux-dev@diy-linux.org Tue Apr 10 20:38:57 2007 From: diy-linux-dev@diy-linux.org (Jon Grosshart) Date: Tue, 10 Apr 2007 16:38:57 -0400 Subject: X11R7 implementation Message-ID: <9cf823c60704101338s9428819neb62ade1f2295a73@mail.gmail.com> ------=_Part_14244_30461277.1176237537935 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Greets all. Thought I'd share a little "beyond the base" stuff with everyone. I typically wouldn't do so, but I think I've come up with something rather cool and some of you may appreciate it for your personal use. I resisted modular X, like a lot of people, for awhile but decided to take the plunge and really try to nail it down and make it as hassle free as possible. But more importantly, I wanted my build method to be able to span multiple releases with little to no script/file modification as possible. So.... I wrote 'picklist'... ;-) http://jaguarlinux.com/pub/DIY/source/x11R7.x/picklist I've been known to be a little hackish with bash here and there, but, it does what it was designed to do... Determine individual module versions based upon what release $VERSION you specify. In short, it comes up with the "blfs wget files" on it's own. So, if your like many people who sit on their hands waiting for BLFS to update it website, don't bother. Grab picklist and extras/$series-order and get building :-) It will also download the modules if you want it to. I suppose it's not something you might appreciate until your on your 2nd or 3rd build of modular X... So.... in theory, your final module lists ($series.lst) should contain the exact same versions as what you would find listed here: (it's a good theory too :-) http://wiki.x.org/wiki/Releases/ModuleVersions The only thing I'm not happy about is the modules that wind up in "older". Anything found in this file (compiz, mkcomposecache, rendercheck) will be greped from /individual, thus being the latest version. Other than those, everything else should be 'stable'... One of the above mentioned modules was accidentally left out of X11R7.2, as near as I can tell, and the others are 'contrib' packages. I wasn't happy with filtering the xcb's thru my version function so I define static versions at the top of the script. I suppose we could do the same with compiz and the others. Well, anyway. Check it out. See what you think. I'd like to change the grep-o and sed-e sloppiness at some point but other than that I'm fairly happy with it. I'm running 7.2.0 on my DIY build right now with David Turner's Cleartype patches/options and it's a flawless build as far as I can tell. I'd be interested if someone decided to pick the script apart to see if it actually holds up to what it's supposed to do. I've done quite a bit of testing with it, but it's quite possible that I've overlooked something. As long as the Xorg repository stays in a correct and orderly fashion, the script shouldn't ever break. If any new modules are added in the future, you will have to append to $CWD/etras/${series}-order, otherwise they'll be missing from your final ${series}.lst... That should be the only modification necessary along with defining $VERSION. On a side note, if you run on an LCD screen, enabling SUBPIXEL_RENDER in freetype2 along with patching libXft and cairo results in amazing font clarity. Truly stunning IMO... I've never been big on such things, but... WOW. Thanks everyone, Jon ------=_Part_14244_30461277.1176237537935 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Greets all. Thought I'd share a little "beyond the base" stuff with everyone. I typically wouldn't do so, but I think I've come up with something rather cool and some of you may appreciate it for your personal use.

I resisted modular X, like a lot of people, for awhile but decided to take the plunge and really try to nail it down and make it as hassle free as possible. But more importantly, I wanted my build method to be able to span multiple releases with little to no script/file modification as possible. So.... I wrote 'picklist'... ;-)

http://jaguarlinux.com/pub/DIY/source/x11R7.x/picklist

I've been known to be a little hackish with bash here and there, but, it does what it was designed to do... Determine individual module versions based upon what release $VERSION you specify. In short, it comes up with the "blfs wget files" on it's own. So, if your like many people who sit on their hands waiting for BLFS to update it website, don't bother. Grab picklist and extras/$series-order and get building :-) It will also download the modules if you want it to. I suppose it's not something you might appreciate until your on your 2nd or 3rd build of modular X... So.... in theory, your final module lists ($series.lst) should contain the exact same versions as what you would find listed here: (it's a good theory too :-)

http://wiki.x.org/wiki/Releases/ModuleVersions

The only thing I'm not happy about is the modules that wind up in "older". Anything found in this file (compiz, mkcomposecache, rendercheck) will be greped from /individual, thus being the latest version. Other than those, everything else should be 'stable'... One of the above mentioned modules was accidentally left out of X11R7.2, as near as I can tell, and the others are 'contrib' packages. I wasn't happy with filtering the xcb's thru my version function so I define static versions at the top of the script. I suppose we could do the same with compiz and the others.

Well, anyway. Check it out. See what you think. I'd like to change the grep-o and sed-e sloppiness at some point but other than that I'm fairly happy with it. I'm running 7.2.0 on my DIY build right now with  David Turner's Cleartype patches/options and it's a flawless build as far as I can tell. I'd be interested if someone decided to pick the script apart to see if it actually holds up to what it's supposed to do. I've done quite a bit of testing with it, but it's quite possible that I've overlooked something. As long as the Xorg repository stays in a correct and orderly fashion, the script shouldn't ever break. If any new modules are added in the future, you will have to append to $CWD/etras/${series}-order, otherwise they'll be missing from your final ${series}.lst... That should be the only modification necessary along with defining $VERSION.

On a side note, if you run on an LCD screen, enabling SUBPIXEL_RENDER in freetype2 along with patching libXft and cairo results in amazing font clarity. Truly stunning IMO... I've never been big on such things, but... WOW.

Thanks everyone,

Jon
------=_Part_14244_30461277.1176237537935-- From diy-linux-dev@diy-linux.org Tue Apr 24 16:32:39 2007 From: diy-linux-dev@diy-linux.org (George Boudreau) Date: Tue, 24 Apr 2007 12:32:39 -0400 Subject: latest refbuild Message-ID: Hi Greg, While building your latest refbuild I noticed 'gsbuild_base.prep' no longer wraps the test cmds in bash and coreutils. I use the following to sed to wrap the test cmds. sed -i -e '/^if \[ `id -u`/iif [ "$RUN_TESTS" = Y ]; then' \ -e '/^fi/ifi' \ scriptlets/chroot/{bash,coreutils} George From diy-linux-dev@diy-linux.org Wed Apr 25 04:28:29 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Wed, 25 Apr 2007 14:28:29 +1000 Subject: latest refbuild In-Reply-To: References: Message-ID: <20070425042829.GA2163@eyo32.local> On Tue, Apr 24, 2007 at 12:32:39PM -0400, George Boudreau wrote: > While building your latest refbuild I noticed 'gsbuild_base.prep' no > longer wraps the test cmds in bash and coreutils. Are you using the latest gsbuild code from cvs? It should be fine there as far as I know. Yes, I should have put up a new gsbuild tarball months ago.. Regards Greg From diy-linux-dev@diy-linux.org Wed Apr 25 13:39:07 2007 From: diy-linux-dev@diy-linux.org (George Boudreau) Date: Wed, 25 Apr 2007 09:39:07 -0400 Subject: latest refbuild In-Reply-To: <20070425042829.GA2163@eyo32.local> References: <20070425042829.GA2163@eyo32.local> Message-ID: On 4/25/07, Greg Schafer wrote: > On Tue, Apr 24, 2007 at 12:32:39PM -0400, George Boudreau wrote: > > > While building your latest refbuild I noticed 'gsbuild_base.prep' no > > longer wraps the test cmds in bash and coreutils. > > Are you using the latest gsbuild code from cvs? No, still using a modified version of your code. I did not know there was a cvs for gsbuild. > It should be fine there as > far as I know. Yes, I should have put up a new gsbuild tarball months ago.. > > Regards > Greg > > __________________________ > Unsubscribe information at > http://www.diy-linux.org/mailman/listinfo/diy-linux-dev >