Tiny improvements to ESP Ghostscript build rules
Dear List, pst/espgs.html, for ES Ghostscript 8.15.2, was last updated 006-06-21 11:26:07 -0500, but could do with some more work. The 'configure' script tests for the presence of glib-2.0 (by way of gmodules-2.0) and also for glib-1.2. You don't mention glib-2.0, though glib-1.2 is implicit in gtk-1.2 (which, oddly, doesn't seem to be tested for specifically). Was gtk-1.2 a mistake? Less important, but probably relevant in several other pages (I'm too lazy to check...), there's an improvable build instruction too. tar -xvf ../// -C /usr/share/ghostscript && chown -v root:root /usr/share/ghostscript/fonts/* It's true that unpacking as root won't automatically convert to the current root:group, but it can be made to do so with tar -xovf which makes the following chown unnecessary. And, indeed, tar -xmovf will use the current date and time as the modification time-stamp, which is a Good Thing for keeping track of installation times. This seems to me to be more generally useful than whatever date the original tarball preserves, though it is fun to see just how old some of the files in TeTeX are alleged to be (they used to have by far the oldest time-stamps in my system). Yours faithfully, Bernard Leak. _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
"Explanation" in Unzip-5.52 needs work
Dear List, in general/unzip.html (for Unzip, version 5.52: 'live' version was last updated on 2006-06-21 11:26:07 -0500) LOCAL_UNZIP=-D_FILE_OFFSET_BITS=64 is 'explained' with /LOCAL_UNZIP=.../: This sets the compilation flags to allow UnZip to handle files upto 4 GB I suppose it's true that it *does* enable UnZip to handle files up to 4 GB, but all the same I doubt very much that precisely that was meant. I think it might be useful to wave a flag at people not using x86 machines: they should use the target 'linux_noasm' rather than 'linux' . Yours sincerely, Bernard Leak. _ Download the new Windows Live Toolbar, including Desktop search! http://toolbar.live.com/?mkt=en-gb -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
BLFS Exim instructions are randomly out-of-date
Dear List,
http://www.linuxfromscratch.org/blfs/view/svn/server/mail.html#exim
was "Last updated on 2006-06-21 11:26:07 -0500", and seems to have
rather too many old version numbers. The references to
*exim-4.43-2 should, of course, be updated to the relevant version
(4.61 in Book, though 4.63 is bang up-to-date as I type).
Similarly, the Web documentation for 4.6x should be used rather
than the old 4.4x documentation: the site currently has a link to
http://www.exim.org/exim-html-4.62/doc/html/spec_html/index.html .
I think that you should at least mention the tarballs of pre-built
documentation in various formats which are distributed along
with the sources. They are certainly on
the master server at http://www.exim.org/ftp/exim4/ . They are
named
exim-{html,pdf,postscript,texinfo}-.tar.bz2 , and are
available for **4.6{0,1,2,3} releases, among others.
Yours tediously,
Bernard Leak.
_
Windows Live Messenger has arrived. Click here to download it for free!
http://imagine-msn.com/messenger/launch80/?locale=en-gb
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
JDK (1.5.0_08): wrong .jar file name?
Dear List, your mileage may vary (depending on how you get to the file in question), but the name given for the binary .jar component of the JDK sources doesn't match what I found on the Sun web-site. jdk-1_5_0_08-fcs-bin-b03-08_aug_2006.jar is given (with MD5 sum 267653f0e425b4c8f37b918b73e47027) but what I fetched is labelled with the licence used: jdk-1_5_0_08-fcs-bin-b03-jrl-08_aug_2006.jar (but the same MD5 sum). Yours faithfully, Bernard Leak. _ Windows Live Messenger has arrived. Click here to download it for free! http://imagine-msn.com/messenger/launch80/?locale=en-gb -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
RE: GCC-4.3.1, Linux-2.6.26.2
Dear List,
I've had a little experience of the "missing limits.h"
problem. If you allow gcc-4.3.x to produce its purged directory
of modified headers, and don't strip them out, then it works.
Evidently glibc-2.7 is not as fully compatible with gcc-4.3.x as
it is with 4.2.x.
I confess I've not built a 2.6.26 kernel yet. I'll do so soon
(probably tomorrow): I'll add a note to this thread if I run
into any problems.
Bernard Leak.
_
Get Hotmail on your mobile from Vodafone
http://clk.atdmt.com/UKM/go/107571435/direct/01/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
RE: GCC-4.3.1, Linux-2.6.26.2
Dear List, I've been having trouble with my internet connexion, which explains (a) why I am later returning to this issue than I hoped, and (b) why I've only built a raw 2.6.26 rather than a later variant. But build it I have, with no special problems - at least, not with glibc. I find that the 2.6.26 series has (finally) broken the frandom kernel patch... ah, well. I should explain something I was taking excessively too much for granted, namely that I was using the then LFS patch for dealing with the glibc problem! I took a copy when it was called http://www.linuxfromscratch.org/patches/downloads/glibc/glibc-2.7-roland_config-1.patch It's now http://www.linuxfromscratch.org/patches/downloads/glibc/glibc-2.7-gcc-4.3.patch This is functionally the same patch, except that it only patches 'configure', not 'configure.in' as well. Personally I find the omission annoying (what if I want to make my own changes too?) but there it is. Apart from that, the only "dangerous bend" is that you must *have* the fixincludes directory (ignoring the LFS instructions for GCC-4.2.x), which is where I came in. Bernard Leak. _ Win New York holidays with Kellogg’s & Live Search http://clk.atdmt.com/UKM/go/107571440/direct/01/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
RE: GCC-4.3.1, Linux-2.6.26.2
Dear List, I've been using gcc-4.3.1 for the 20080711 version of LFS, but with almost all packages as recent as I can get. I'm even living with groff-1.19.2, though I may downgrade to groff-1.18 so I can use the patch. The most important exceptions so far are that I'm only using grub 0.97 (not 1.x) and libtool-1.5.26 (not 2.x). The state of the LFS patches suggests that there exists a shadow-4.0.18.2 , but I can only find shadow- 4.0.18.1 . The only special changes I've had to make have been to deal with the gcc dependencies. Since I've had to add gmp and mpfr, I've allowed more drastic changes. I also build Ada, and I try to use a build configuration as near as possible to my final intentions throughout. Since this means that (e.g.) I build the gcj libraries each time I build gcc, I don't mind spending a little time on what are technically redundant builds of some of the dependencies, just to be sure. This means that I need (a) GNAT from somewhere as well as a C compiler (b) gmp and mpfr and I also choose to have *external* installations of (c) zlib and libunwind Also, for treelang, I need (d) flex and bison gmp I build with --without-readline to insulate me from the original host copy of readline. mpfr I configure with --enable-shared, but I think this is redundant. That way, without configuring for full library paths, the only dependencies are straightforward unversioned use of libc.so.6, the usual linux-gate and ld links, and mpfr's use of libgmp. There is no problem carrying forward copies of these libraries across successive builds of gcc and ld (in binutils). However, since none of them takes long to build, test or install, I simply add in extra builds. Since the use of flex and bison is a build-time dependency for treelang, even paranoia does not require me to build them more often than initially (before the very first gcc build of chapter 5) and then as directed by LFS. gmp, mpfr, zlib and libunwind I go overboard by building initially (along with the first binutils build), again as soon as gcc and binutils have been built a second time, at the beginning of the chapter 6 build, and again after the final builds of gcc and binutils. This means I actually build the zlib package eight times! Bernard Leak. _ Make a mini you on Windows Live Messenger! http://clk.atdmt.com/UKM/go/107571437/direct/01/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
First console command completes but ...
Dear All, apologies if I'm doing something completely stupid. (or duplicating an existing question - though I don't think I am). I've followed LFS 6.0 very, very nearly 100%: see later for differences (a list complete in intention: certainly no other differences looked important for me to take note of them...) None of the changes seems to explain what I see. When I reboot into the LFS bare-bone system I get a thoroughly normal-looking boot (I have set the boot option for "nosplash" so I get lots of gory details). I emerge into a login prompt, and can log in as root. So far so good. Now, the console accepts my first command, spits out the output as requested, and then seems to hang without actually returning control to the calling shell. What I type is echoed, and 'return' appears as a newline, but I get no other response. I can force a reboot with Ctrl-Alt-Del, but without another machine to play with I can't do much else. Looking over /var/log/sys.log from my other installation, I get no warnings or errors (apart from an irrelevant minor whinge about an NTFS partition). I always get the useless (and, alas, familiar) message in /var/log/sys.log : *"No module symbols loaded* - kernel modules not enabled" Ho-hum, klogd being unhelpful as usual. /dev/vcs1 and /dev/vcsa1 bounce in and out of existence as udev gets going, but there are no notable surprises (both end up created and remaining until I shut down). Does anyone have anything to offer here? My host (and target!) machine is new-ish and boring i686-pc-linux (actually P4 on an Intel 845PE motherboard) Host build tools (for building the bootstrap tools): kernel 2.6.11.6-mykernel-01 (very, very close to unmodified, but I have added some private FS modules of my own). binutils-2.15.90.0.3 gcc-3.4.3 glibc-2.3.3 Not quite following Book: binutils 2.15 (which I think is *later* than the 2.15.91.0.2 specified in the Book) glibc 2.3.5 rather than the CVS snapshot of 2.3.4 (not out, I think, when the Book was in preparation, and of course includes the changes which prevented 2.3.4 from working) man 1.5o2 rather than 1.5o (1.5o in fact was hard to track down: the only obvious difference was that at least one patch had already been (partially) taken, but the ChangeLog in the tarball doesn't even record the change of version) I'm using almost pure udev; /dev/console, /dev/null and /dev/tty0 are statically set up initially. This doesn't seem to be a problem. Finally, I left my ethernet card unconfigured (waiting to use DHCP following BLFS). This is unimportant at present, though it produces an "eth0 not configured" warning while running 'network start'. Not deviations from Book, really, but worth noting: I already have a working grub installation, so I simply added a new entry to /boot/grub/menu.lst. /boot is not LFS-specific: I use the same partition for my current system and for LFS. I've built my kernel both with "mostly modules" and "modules only where necessary". This makes no difference to the relevant behaviour. However, the version without modules doesn't give me the special vga=788 requested (just 640x480, ugh) Most odd - I could understand a missing entry in modules.conf, but that would make the moduled version fail, and the (nearly) solidary and monolithic version succeed! I dare say I've got some operation fail *because* a module can't be loaded, even though the functionality is in the kernel anyway. But this is unimportant anyway. Complete build scripts and logs are available for the LFS build. All commands send output (standard and error) to the logs, except when output is being copied / appended to some other file anyway. Bernard Leak. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Patch for mktemp-1.5 could be improved
Dear List, this arose out of LFS Book 6.0 (though the patch I'm patching has apparently not been changed since). The 'add tempfile' patch for mktemp-1.5 is pointlessly broken if using a separate build directory. (I've seen worse - the build instructions for libxml2-2.6.13 are fine for a separate directory for everything except the testsuite - erm ... - but that's nothing to do with LFS). Assuming that you aren't actually allergic to separate build directories (me, I use them whenever I can), I suggest modifying the patch file mktemp-1.5-add_tempfile-1.patch: where it says +install-tempfile: tempfile +$(INSTALL) -m 0555 tempfile $(bindir)/tempfile have instead +install-tempfile: $(srcdir)/tempfile +$(INSTALL) -m 0555 $(srcdir)/tempfile $(bindir)/tempfile All right, if you *insist* ... here's a diff you can give to 'patch': diff -ru mktemp-1.5-add_tempfile-1.patch.old mktemp-1.5-add_tempfile-1.patch --- mktemp-1.5-add_tempfile-1.patch.old 2005-04-20 13:59:23.187401832 +0100 +++ mktemp-1.5-add_tempfile-1.patch 2005-04-20 13:59:56.087400272 +0100 @@ -11,8 +11,8 @@ install-man: $(INSTALL) -m 0444 $(srcdir)/$(PROG).$(mantype) $(mandir)/man1/$(PROG).1 -+install-tempfile: tempfile -+ $(INSTALL) -m 0555 tempfile $(bindir)/tempfile ++install-tempfile: $(srcdir)/tempfile ++ $(INSTALL) -m 0555 $(srcdir)/tempfile $(bindir)/tempfile + check: @echo nothing to check Bernard Leak. (bernard at brenda hyphen arkle dot demon dot co dot uk) -- "Before they made me, they broke the mould" -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: First console command completes but ...
(apologies if this doesn't get linked to Steve Crosby's reply... it's not
quite obvious how to force it if it doesn't happen automagically)
Dear All, and more particularly Steve Crosby,
you have me
bang to rights. With hindsight I really should have checked the "live"
versions of LFS for glibc-2.3.5-related patches. Oops!
Anyway, after that my shiny new LFS system boots just fine.
Time to back it all up...
Bernard Leak.
--
"Before they made me, they broke the mould"
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
gawk-3.1.4 and glibc-2.3.5: broken combination?
Dear List, H'mmm - I tried searching for a prior posting on this subject and got Index file error: Index file 'lfs-dev.swish' and property file 'lfs-dev.swish.prop' are not related. But that's by the way. The problem was discovered while working through blfs (building libgpg-1.0), but the problem is with the original lfs-built tools. I've been able to reproduce it with less input and a simpler script as follows. Set up files for testing as follows: cat > test.in< test.awk
Re: gawk-3.1.4 and glibc-2.3.5: broken combination?
Dear List, sorry to lose the threading - I asked a question about avoiding this in the recommended place (a message to [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>) and found it had been sent to a mailing list and bounced from it! [Thanks] Thanks in particular to Matthew Burgess. By the sound of it, it's not just me, and it's new since glibc-2.3.3: true LFS 6.0 fanatics with the 2.3.4 CVS snapshot version of glibc should see it as well as me. Time to report to gawk and glibc (I do hope it's not glibc...) ["//" should be "/"] A mistake made in cutting-and-pasting (somehow). The scripts I used didn't have the extra '/' at the beginning. [A follow-up] For anyone with a similar set-up (glibc >= 2.3.4, gawk-3.1.4): Can you build libgpg-error-1.0 with your toolset? This should only occupy you for a few seconds: it's a small package. If it fails with broken headers because gawk has created them wrongly then it takes even less time! Bernard Leak. -- Before they made me, they broke the mould. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gawk-3.1.4 and glibc-2.3.5: broken combination?
Dear List,
err... Andrew Fyfe clearly doesn't have
the same problem that I see (and neither, I suppose
did whoever set up the instructions for blfs 6.0 -
which is why I thought it was glibc-2.3.5 related).
That he goes on not to see the consequential
problem (which I saw first) with libgpg-error is
not very surprising.
He asks
Have you tried recompiling gawk??
I've already produced six distinct builds, many of them
compiled several times (for one reason or another).
How many more times would he like me to try? Does he
recommend any particular clothes, or phases of the moon?
Seriously: I wonder whether the difference is in the glibc
build. He has 2.3.5 too, but built with gcc-3.4.4,
whereas mine is still built with gcc-3.4.1 like the rest
of LFS. I'll try re-building glibc (O joy!) and see what
I get.
Bernard Leak.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: gawk-3.1.4 and glibc-2.3.5: broken combination?
Dear List,
apologies for the delay. This is
just reassurance, confirming what others have
reported. And, again, apologies for the broken
threading.
I've just done a clean blfs-6.1-pre1 build, with
no changes except
(a) adding a few languages to the GCC build
(the easy way of not losing Ada: always
build it! The final build is of the
full set of supported languages).
(b) glibc-2.3.5 (the important one!).
Note that everything in sight has been built with
gcc-3.4.3.
I no longer see the problem with gawk-3.1.4 which
I had when I built glibc-2.3.5 with gcc-3.4.1
(irrespective of the gcc version used to build gawk).
Evidently the problem is not exposed in this
set-up, though I have applied none of the specific
patches to gawk which are (also) supposed to
eliminate the problem. Whether that means the
problem has "gone away" or not I can't say.
Bernard Leak.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: gawk-3.1.4 and glibc-2.3.5: broken combination?
Dear List, before I spread any more confusion: my last message was entirely wrong. Grovelling apologies. After correcting a silly mistake (which led to me using the wrong glibc) I still see the problem I reported earlier. That is, building LFS-6.1-pre1 but with glibc-2.3.5 rather than glibc-2.3.4 giveas a broken version of gawk-3.1.4 . Everything in the build was done with gcc-3.4.3. Bernard Leak. -- Before they made me, they broke the mould -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gawk-3.1.4 and glibc-2.3.5: broken combination?
Dear List, ... confusion worse confounded: as has been suggested, the problem is locale-related, and now does not seem to have anything to do with the glibc version (hurrah!). The remarks previously posted to the list suggest that it is indeed a gawk-3.1.4 bug. en_GB is all right en_GB.iso88591 is all right en_GB.utf8 shows the problem (gawk-3.1.4 misbehave gawk-3.1.3 seems correct) The text being handled here contains nothing but elementary ASCII (invariant subset), so the preferred encoding shouldn't matter as much as all that... but there it is. The output from 'locale' in the failing case (on my LFS build) is LANG=en_GB.utf8 LC_CTYPE="en_GB.utf8" LC_NUMERIC="en_GB.utf8" LC_TIME="en_GB.utf8" LC_COLLATE="en_GB.utf8" LC_MONETARY="en_GB.utf8" LC_MESSAGES="en_GB.utf8" LC_PAPER="en_GB.utf8" LC_NAME="en_GB.utf8" LC_ADDRESS="en_GB.utf8" LC_TELEPHONE="en_GB.utf8" LC_MEASUREMENT="en_GB.utf8" LC_IDENTIFICATION="en_GB.utf8" LC_ALL= The alternative forms were achieved with export LC_ALL=en_GB.iso88591 export LC_ALL=en_GB.utf8 with the predicatable output from `locale'. These names are as returned by locale -a . In my "normal" host set-up (Mandrake-10.1 but with my own unpatched gcc-3.4.3 my own (not relevantly patched) kernel 2.6.11.6 Mandrake's glibc-2.3.3) I see similar behaviour, but the names returned by locale -a , and used for testing, are en_GB (the default) en_GB.ISO-8859-1 en_GB.UTF-8 Bernard Leak. -- Before they made me, they broke the mould -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Book for 6.1-pre1: a few miscellaneous nits
current, GCC (e.g., gcc-3.4.1) with C and Ada enabled Use this GCC version to bootstrap the desired version of GCC, with at least C and Ada: e.g., for the Phase 1 bootstrapping of GCC in 5.4 The Phase 2 build in 5.11 should then enable Ada as well as C and C++. Finally, the build in 6.14 may as well enable everything you want. If you build C, C++ and Ada then you won't save much by omitting f77, objc and treelang, but if you don't want gcj then you can spare yourself a lot of building time and space by omitting that - not that the VM is very large, but the Java libraries are (very). *** Finally, I'd like to say how impressed I am with the quality of the writing, and the general will-to-accuracy. Observing the many, many careful improvements even between 6.0 and 6.1 warms the cockles of my heart to only a little below freezing-point. If I ever tire of the universe and sweep it into oblivion, it may perhaps console you to think that you have deferred this by a few minutes. Bernard Leak. -- Before they made me, they broke the mould -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Separate build directories
Dear List, I've been cleaning up the makefiles for some of the bits of BLFS, mostly with a view to enabling building away from the source tree. In a sense this is repairing what isn't broken, but others also may want to do it. Is there an interest in patches to achieve this? I have several lined up, in various stages of elegance. All of them work for BLFS building, but I haven't tested for every possible invocation case. In particular, "make clean" may be broken - but of course that's trivial with a separate build directory! [A puzzle: building gpm-1.20.1] I'm scratching my head over the behaviour of the main build inside /contrib. If the build directory is not the same as the source directory, there are some minor problems (mostly a matter of supplying a $(srcdir) prefix where needed, though there are a few other cases where more complicated dancing is called for). I now have it working, but with a very confusing difficulty, which at present I hack past in a very brutal fashion. In between exiting from the main build rule in /contrib and exiting from the contrib directory to return to the top-level Makefile in a single file is deleted, namely rm emacs/t-mouse.el This is an Emacs Lisp source file. Emacs insists on putting the compiled .elc file in the same directory as the source file, so I must copy the source file to the build directory, or at least put in a link to it. Presumably the original is NOT deleted if the build directory is the same as the source directory (I never had trouble with this before...)! There doesn't seem to be anything relevant in the explicit Makefile rules which explains this behaviour. Presumably an implicit rule is being followed - but then, what rule is it, defined where, and why? Bernard Leak -- Before they made me, they broke the mould -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Some improvements to the init.d/functions script
Dear List, here are some suggested alterations to 'functions' from the lfs bootscripts. None of these are functional changes, but should make the script clearer to people reading it, or maybe just less annoying to me... Just typos: Dimentions <- Dimensions Cursur <- Cursor unforseen <- unforeseen becasue <- because Bad punctuation: Warning, when <- Warning: when Poor wording: which is depreciated <- which is deprecated This occurs more than once. Typo AND poor wording: Invalid of excessive <- Invalid or too many This occurs more than once. An argument can be individually 'excessive' 'excess' was meant - but 'too many' is better still. More confusing still: (TENTATIVE CORRECTION ONLY) This depreciates getpids <- This will make getpids obsolete I suspect 'deprecates' was meant, sort of, but what does that mean? One deprecates things by, er, deprecating them. This is my guess at what was meant. Bernard Leak. -- Before they made me, they broke the mould. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
module-init-tools-3.2.2 : any ideas what I'm doing wrong?
Dear List, in what is (or was a few days ago!) the 'live' LFS Book (LFS-BOOK-SVN-20051223), I can't get the test-suite for 6.50, Module-Init-Utils to run *at all*. Ignoring the test result, everything seems to build, but I haven't dared install it on top of the existing version. In a fit of amazing helpfulness, the failure does its best to delete its own audit trail. The first test to be run, tests/test-depmod/01backcompat.sh , produces no output and returns an error, and the built objects are deleted before I can look at them! Doubtless with patience and time I could modify the makefile and the associated scripts until I could get some sort of output, but I'd like to be told whether anyone else knows what I'm doing wrong... I'm fairly sure I must have crocked some part of my toolchain very heavily, but for some reason it hasn't showed up hitherto (and, yes, I do run testsuites and check the output!). A virtually identical problem (well, as far as one can tell!) showed up on a German web-forum a few years ago, but only got "Gosh, really? I don't understand" as a response. I've been rebuilding everything which has changed between 6.1pre to the (then) live state - this was at about 23rd December - with the latest versions. I'd already moved to GCC-4.0.2 and glibc-2.3.6 before I started. Note that this is not a 'clean' LFS build - I have a full LFS build already (indeed, rather a lot of BLFS on top of it), and I am replacing it "in place", basing myself on Chapter 6, but with rather fewer suppositions about what's already there than are made in Chapter 6, so I don't trample all over existing configurations. Bernard Leak -- Before they made me, they broke the mould -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
module-init-tools-3.2.2 : any ideas what I'm doing wrong?
Dear List, I've found the problem: the testsuite simply *assumes* that '.' is in the path. This is true during the LFS build, but wasn't when I returned to it with my 'running' set-up. This may be thought worth a note, as it's easily got wrong and the output is quite exceptionally unhelpful! Bernard Leak -- Before they made me, they broke the mould -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
