Re: 2.6.15 Hotplugging/Coldplugging via udev
Dan Nicholson wrote: He sent this email [2] to the llh-announce list in November about being swamped with work, but nothing's happened since then. Any more information about this? Nope, that's the last email I've received on the subject. I didn't spot the fact that he sent it to the llh-announce list, otherwise I would have just sent a link to the archives like you just did :-) Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 2.6.15 Hotplugging/Coldplugging via udev
Matthew Burgess wrote: Dan Nicholson wrote: He sent this email [2] to the llh-announce list in November about being swamped with work, but nothing's happened since then. Any more information about this? Nope, that's the last email I've received on the subject. I didn't spot the fact that he sent it to the llh-announce list, otherwise I would have just sent a link to the archives like you just did :-) and I have just asked about possibly-dead LLH on LKML: http://lkml.org/lkml/2006/1/7/51 -- Alexander E. Patrakov Don't mail to [EMAIL PROTECTED]: the server is off until 2006-01-11 Use my GMail or linuxfromscratch address instead -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
i18n patches.
Hi! Starting the Spanish translation update I noticed that the i18n patches referenced in the book are yet hosted on the Alexander's home dir. For consintency, and to allow patcheslist.xsl and jhalfs do well their job, that patches must be placed into the Patches Project repository, and chapter03/patches.xml be fixed after that. Can someone with commit priviledges on the patches repo do that ASAP? Thanks. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Jim's Udev package (part 3)
On Fri, 6 Jan 2006 11:22:53 -0800 Dan Nicholson [EMAIL PROTECTED] wrote: To both guys, Thanks for all the hard work on the hardware issues. I promise it is appreciated by others on the list whether they're vocal about it or not. I don't think I'm alone when I say that I'm eager to see how this shakes out. +1 Looking forward to seeing the finished version. I'll be waiting for an unpatched kernel though. R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Berkeley DB
Hi all, The new database package in the LFS SVN book is referenced as the DB package. This is incorrect and should be fixed. The package is known as, and is referenced by its maintainers as Berkeley DB. And, because this package will also have to stay in the BLFS book, and is referenced as Berkeley DB there, for consistency sake, it should be renamed in LFS. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 08:14:01 up 104 days, 17:38, 3 users, load average: 1.34, 1.13, 0.67 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: More ICA
On 1/7/06, Greg Schafer [EMAIL PROTECTED] wrote: snip the business Wow, that's some serious analysis, dude. It also proves that my earlier flex must be before bison is bogus. Seems that adding bison back into Ch. 5 would do the trick, but maybe there's a better solution. This has inspired me to work on the e2fsprogs differences, and not just make guesses about what's going on. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Man-DB and Berkeley DB
Richard A Downing wrote these words on 01/07/06 08:52 CST: Can someone point me to the discussion thread that decided this change of man package? Unfortunately, for these very reasons, there really was no discussion of putting in UTF-8 in LFS trunk, it was more of a just do it. Not that it is bad, mind you, but for those that sort of just skim over i18n and UTF8 threads, it may have come as a surprise. Anyway, man-db and Berkeley DB are required for UTF-8 compatibility. Apparently, the regular 'man' package doesn't work. There was a fairly comprehensive thread not too long ago about should we use GDBM or Berkeley, but you must have missed it. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 09:00:00 up 104 days, 18:24, 3 users, load average: 0.23, 0.05, 0.08 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Man-DB and Berkeley DB
Richard A Downing wrote: Can someone point me to the discussion thread that decided this change of man package? I want to review the reasons to make my own decision on it. There was no discussion thread. All reasons are explained in my man-i18n.txt hint. I _really_ don't want to say Drop all non-ISO-8859-1 manual pages (because I need Russian manual pages that just can't be expressed in ISO-8859-1) or import the whole Hacks section into LFS (because this would confuse Randy). A quick archive search (+man-DB and then +man +Berkeley) didn't reveal anything useful other than it's a better fit for a UTF-8 system. I can see the thread about which db to use, but not the change to man-db from man. Personally, I have no other use for a DB and will probably stick with man. You are free to do so, but only because you use the en_US locale. -- Alexander E. Patrakov Don't mail to [EMAIL PROTECTED]: the server is off until 2006-01-11 Use my GMail or linuxfromscratch address instead -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Jim's Udev package (part 1)
Archaic wrote: I think you might be mistaking me with someone else. I don't recall using anything called nvsound. Sorry -- Alexander E. Patrakov Don't mail to [EMAIL PROTECTED]: the server is off until 2006-01-11 Use my GMail or linuxfromscratch address instead -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Berkeley DB
Randy McMurchy wrote these words on 01/07/06 08:17 CST: The new database package in the LFS SVN book is referenced as the DB package. This is incorrect and should be fixed. Thanks, Ken, for updating the BDB package. However, there are still some references of DB: the title in section 6.27.1, the first sentence of that same section, and the title in section 6.27.2. Additionally, the following items: 1) disk space used should be 94 MB used. 2) 1.2 is more accurate for the SBU measure. 3) it says fix the permissions in the text for the chown commands. However, it might be better as fix the ownerships. 4) could you somehow place a note in an appropriate place that there are BLFS instructions to build BDB as well? Folks might not realize that they need to install other dependencies if they want to build the RPC server or additional language bindings that they may be used to. There will be no more references in BLFS of BDB as a dependency, therefore, a note in LFS is the only way that they might remember to build the functionality they are used to. Here is an example of such a note: There are instructions to build this package in the BLFS book if you need to build the RPC server or additional language bindings. The additional language bindings will require additional packages to be installed. The BLFS instructions are located at [place URL here]. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 11:34:00 up 104 days, 20:58, 3 users, load average: 0.16, 0.12, 0.34 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Man-DB and Berkeley DB
Richard A Downing wrote: Can someone point me to the discussion thread that decided this change of man package? I want to review the reasons to make my own decision on it. http://linuxfromscratch.org/pipermail/lfs-dev/2005-December/054909.html That's not the thread that decided it, but it's the best explanation I've seen of exactly what's wrong with man, and why man-db works. (In other words, it's the reasons you want to review.) In short: Regular man requires all sorts of hacks from the user before it will work in a UTF-8-charset locale. man-db knows all the hacks, and can build a correct pipeline automatically based on the contents of the shell $LANG variable. (I would assume that it follows the normal rules of the LC_* variables: check $LANG first, then $LC_CTYPE, then $LC_ALL, with later variables overriding earlier ones. But I don't know that for sure.) signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Belgarath
Jeremy Huntwork wrote these words on 01/07/06 12:39 CST: I'm sure that slowed down a bunch of running cron jobs. When they finally finish, belg should hopefully recover. Does anyone periodically do system clean-up on Belg? Are there cron jobs that are set up to do automated clean-up? I noticed there are files in /tmp that are over 4 months old. Not that this is the reason for today's hiccup, I'm just wondering if anyone is tasked with system-admin related responsibilities. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 12:41:00 up 104 days, 22:05, 3 users, load average: 0.00, 0.05, 0.23 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Man-DB and Berkeley DB
On Sat, 07 Jan 2006 20:09:47 +0500 Alexander E. Patrakov [EMAIL PROTECTED] wrote: Richard A Downing wrote: Can someone point me to the discussion thread that decided this change of man package? I want to review the reasons to make my own decision on it. There was no discussion thread. All reasons are explained in my man-i18n.txt hint. I _really_ don't want to say Drop all non-ISO-8859-1 manual pages (because I need Russian manual pages that just can't be expressed in ISO-8859-1) or import the whole Hacks section into LFS (because this would confuse Randy). A quick archive search (+man-DB and then +man +Berkeley) didn't reveal anything useful other than it's a better fit for a UTF-8 system. I can see the thread about which db to use, but not the change to man-db from man. Personally, I have no other use for a DB and will probably stick with man. You are free to do so, but only because you use the en_US locale. I use en_GB.iso-8859-15. I want to make it quite clear that I SUPPORT making the book UTF-8 enabled as fast as possible. I thought I had missed the discussion, and wanted to see the reasoning. Thanks. R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Berkeley DB
Ken Moffat wrote these words on 01/07/06 12:56 CST: Disagree. 77.9 MiB on my first build, so yes, more than it says, but I can't get near 94 (my understanding is that we use MB as an abbreviation for MiB, I have 79804 KiB as the raw figure). Hey I was just trying to be helpful. And perhaps you are right as my two testing builds today were BLFS style builds which build the JAVA and TCL bindings and the RPC server. I showed 60 MB in the source tree and 34 MB of installed files. I forgot about this extra stuff which is odd, because I did one more build *LFS* style to measure SBU. I didn't even think about disk space. Thanks Ken. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 12:57:00 up 104 days, 22:21, 3 users, load average: 0.10, 0.04, 0.10 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Man-DB, BDB --compat-1.85
I noticed that this switch is in the LFS book for BerkyDB, I haven't built that for some time (when something says it needs a DB that I'm testing). Does Man-DB need this? I'm amazed if it does - the rationale for using it is that it's maintained and modern and handles all sorts of UTF-8 stuff. And we are only putting BDB in for Man-DB. BTW, I'm building it all now, for solidarity :-) R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Man-DB, BDB --compat-1.85
Richard A Downing wrote these words on 01/07/06 13:26 CST: I noticed that this switch is in the LFS book for BerkyDB, I haven't built that for some time (when something says it needs a DB that I'm testing). Does Man-DB need this? I'm amazed if it does - the rationale for using it is that it's maintained and modern and handles all sorts of UTF-8 stuff. And we are only putting BDB in for Man-DB. Not arguing against Richard's case, just making my opinion known I think the --compat-1.85 should stay. BDB is updated so often and so many packages need to look for specific versions (BDB-3, BDB-4.1, BDB-4.2, BDB-4.3 and now BDB-4.4), but then many will fall back to the plain old BDB (libdb.so and not libdb-x.x.so) with the 1.85 compatibility and it works. What is the harm in retaining it? /not arguing -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 13:31:00 up 104 days, 22:55, 3 users, load average: 0.00, 0.13, 0.37 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Man-DB, BDB --compat-1.85
On Sat, 07 Jan 2006 13:37:49 -0600
Randy McMurchy [EMAIL PROTECTED] wrote:
Richard A Downing wrote these words on 01/07/06 13:26 CST:
I noticed that this switch is in the LFS book for BerkyDB, I haven't
built that for some time (when something says it needs a DB that I'm
testing).
Does Man-DB need this? I'm amazed if it does - the rationale for
using it is that it's maintained and modern and handles all sorts of
UTF-8 stuff. And we are only putting BDB in for Man-DB.
Not arguing against Richard's case, just making my opinion known
I think the --compat-1.85 should stay. BDB is updated so often and
so many packages need to look for specific versions (BDB-3, BDB-4.1,
BDB-4.2, BDB-4.3 and now BDB-4.4), but then many will fall back to
the plain old BDB (libdb.so and not libdb-x.x.so) with the 1.85
compatibility and it works.
What is the harm in retaining it?
/not arguing
Good points. I wouldn't see that as I only build it occasionally and
then for a specific package. As it happens, until Man-DB came on the
scene (for me about 3 hours ago when I reviewed gmane.linux.lfs-devel)
nothing I ever built that REQUIRED BDB stayed on the system long :-)
Although this is an argument for having it in BLFS, I'm not sure about
LFS where BDB's extra libs are bloat.
Now, I have to say that having built it, man-DB works very well, and
produces very nice readable pages fast. I don't know if it's connected,
but a longstanding problem with xman rendering seems to have
dissappeared too.
R.
{Randy not arguing? He must be ill.}
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: FAQ CONFIG_DEVPTS_FS=y
On Sat, Jan 07, 2006 at 08:55:34PM +, Richard A Downing wrote: Recent kernels don't seem to support this configuartion switch any more. Does this mean the FAQ needs adjusting? CONFIG_DEVPTS_FS=y It's there, but only if you select config for small systems or whatever it is called. Otherwise, it is just a default option. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Berkeley DB
On Sat, 7 Jan 2006, Randy McMurchy wrote: Ken Moffat wrote these words on 01/07/06 12:56 CST: Disagree. 77.9 MiB on my first build, so yes, more than it says, but I can't get near 94 (my understanding is that we use MB as an abbreviation for MiB, I have 79804 KiB as the raw figure). Hey I was just trying to be helpful. And perhaps you are right as my two testing builds today were BLFS style builds which build the JAVA and TCL bindings and the RPC server. I showed 60 MB in the source tree and 34 MB of installed files. I forgot about this extra stuff which is odd, because I did one more build *LFS* style to measure SBU. I didn't even think about disk space. Thanks Ken. No worries, Randy. I usually find your space measurements close to my own, so the big difference puzzled me. Still got to get through my other edits. Ken -- 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: Changing readjusting toolchain section
On 1/7/06, Ken Moffat [EMAIL PROTECTED] wrote: Thanks for doing the analysis. I suspect we are probably going to move to something like Tushar's method documented towards the end of http://bugs.linuxfromscratch.org/show_bug.cgi?id=1677 I kind of like Tushar's thing, although if you have to go back into /tools to work on something your specs file is hammered. Greg's solution requires a bit more typing, but is a cleaner break from Ch. 5. I'm not close to starting testing for this, but I hope to get a round tuit in a day or two. I'm also wondering if it will clear up some of the 'transient' differences in my ICA analysis. I'm not testing it yet. Maybe not for a couple days. I was playing around with it, then just decided to go full blown analysis. At least introducing Man-DB and Berkeley hasn't brought any new differences, and Alexander's manconfig.h.in gives a better build IMHO. Awesome, and I totally agree about the coolness of manconfig.h.in. If you ever looked at the man build files, it's pretty hacky. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: More ICA
On Fri, 6 Jan 2006, Chris Staub wrote: Or replace creating with customizing. Thanks, done. Ken -- 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: More ICA
On Sat, 7 Jan 2006, Greg Schafer wrote: I've just managed to reproduce this in a DIY build by dropping M4, Bison and Flex from the temptools phase. Hmm, this is a bizarre one... check out the following.. By retaining the finished Bison build dirs from each iteration and diffing them, I was able to establish the problematic object file: src/parse-gram.o Thanks for the analysis, Greg. Looks like saving the build directories is a worthwhile thing to do when comparing builds. Ok, the cause of the difference is now known. Luckily, it looks like a fairly minor issue. Nevertheless, it should be fixed in order to attain clean ICA results. It also proves that dropping packages from Ch 5 should not be done lightly.. Equally, just because we're giving dependencies a thorough going over at the moment doesn't mean that they're set in stone - the hardcoded /tools/bin/grep seems to be new with libtool-1.5.22 (or more accurately, the 1.5.18 on this box doesn't have it). I suppose the price of purity will be eternal vigilance. Ken -- 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: r7256 - in trunk/BOOK: chapter01 chapter06
Author: ken Date: 2006-01-07 15:12:20 -0700 (Sat, 07 Jan 2006) New Revision: 7256 Modified: trunk/BOOK/chapter01/changelog.xml trunk/BOOK/chapter06/chapter06.xml Log: Build mktemp earlier, for gcc's gccbug which now wraps mktemp in 'if [ yes = yes ];' instead of 'if [ no = yes ];'. This is a questionable change. Ken, do you realize that `gccbug' is almost never used these days and is in fact scheduled for future removal by upstream? Sure, it's an ICA difference (albeit only an ASCII one), but it's harmless and the reason for it is understood. You've now changed the order of the toolchain packages which is setting a bad precedent IMHO. All this alphabetical stuff was never meant to upset the toolchain apple cart. If you really want to get rid of the diff then you'd be better off rm'ing gccbug altogether.. or even installing mktemp in Ch 5. The point of ICA is to understand any differences and fix if necessary. Making gratuitous changes like this just to get cleaner ICA results is very wrong IMHO. 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: r7256 - in trunk/BOOK: chapter01 chapter06
On Sat, 7 Jan 2006, Jeremy Huntwork wrote: Not to mention that order changes are being done in the alphabetical branch so that we don't upset whatever we have working in trunk. Let's focus ICA's and purity on the poorly named alphabetical branch and leave trunk alone completely in this regard. Then when we know we have a system in the alpha branch that builds itself without differences, we can bring it all over into the trunk with a merge. Partly, it's a difference of opinion about working. As with all of my commits, I'm willing to believe they can be wrong, or mistaken. That's one of the reasons I try to make them atomic. But certainly, you'll probably want r7257 (move grep before libtool) to fix a hardcoded '/tools' in the libtool script. Ken -- 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: r7256 - in trunk/BOOK: chapter01 chapter06
Ken Moffat wrote: I'm not sure I fully understand your point, you seem to be saying that gcc might be at risk from mktemp ? Sorry, I guess I wasn't quite clear. What you've done is make a build order change by inserting a questionable package smack-bang in the middle of the toolchain sequence. This is the bad precedent I was referring to. While it won't hurt in this instance, IMHO the current toolchain sequence should not be meddled with in this fashion. God only knows how many years it's taken us to get it to its current state :-) I believe it also reduces toolchain education by taking away focus from the key components. 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: More ICA
Greg Schafer wrote: /* Define to 1 to internationalize bison runtime messages. */ -/* #undef YYENABLE_NLS */ +#define YYENABLE_NLS 1 Bingo! This looks like the culprit. snip I'll try and figure out a good fix tomorrow.. Hmmm, AFAICS there is no easy way to fool configure into doing what we need. This is the best I can come up with for now. After running configure, do this: echo '#define YYENABLE_NLS 1' config.h I can confirm it fixes the ICA problem. Just to reiterate, the effects of this bug are fairly minor. ISTM that Bison-generated parsers will not print diagnostics in the user's native language. More information in the manual: info (bison)Internationalization 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: r7256 - in trunk/BOOK: chapter01 chapter06
On Sun, 8 Jan 2006, Greg Schafer wrote: While it won't hurt in this instance, IMHO the current toolchain sequence should not be meddled with in this fashion. God only knows how many years it's taken us to get it to its current state :-) I believe it also reduces toolchain education by taking away focus from the key components. OK Greg, I see your point now. Yes, I don't want to go back to LFS-4. I'll look at reversing this and kicking gccbug into shape. Ken -- 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: r7256 - in trunk/BOOK: chapter01 chapter06
Ken Moffat wrote: But certainly, you'll probably want r7257 (move grep before libtool) to fix a hardcoded '/tools' in the libtool script. Yes, this is new as of libtool-1.5.22. I only noticed this yesterday myself in my latest ICA run. The problem is triggered because the latest libtool tarball was generated with a beta version of Autoconf (2.59c) which changes the `egrep' searching code. At first glance, the effects of this bug look serious enough to break the system installed libtool. I'll soon make a similar build order change in the DIY build. Regards Greg PS. I'm really glad that Ken and Dan are applying ICA to LFS builds. It's all good :-) -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
