> You can look at /mnt/lfs/jhalfs/lfs-commands to see what the
> instructions were used and compare to your scripts.
If I understand how jhalfs works, though I haven't investigated for a
few years, what it does is extract the XML for the commands in the book?
I SHOULD have the same thing from my C&P, and if I screwed up, I need to
fix what I did wrong in any case.
> > I accept I'm going to have to start over,
I did last night, backed everything out to just my original
"distribution" files. That hadn't been tested and needed to be!
> The script checks the host system requirements for you and if
> something is missing, tells you.
There's a script for that in the book which I lifted as the first to
be run. ;-)
> Getting old is better than the alternative.
So I always hear, but it doesn't make my back hurt less from shovelling
tree droppings off a valley on the roof Saturday.
> I saw in one of your posts that, since make exited with an error, you
> thought the failure in the test was likely to be serious.
>
> But what I see above seems just to be a normal exit after all tests
> have been run, and one of them had a error. I mean make exited with an
> error (normal, there's one!), but after doing its whole job.
That wasn't the whole log (obviously). I expected the upstream to have
accounted for all the trivial errors. Well, we'll see on the rebuild.
I can diddle the make check sequence so it doesn't drop out easily
enough ("make -k check || :"), but I regard that as a very bad habit to
adopt! The book says running the tests and generally good results is
critical.
> Did you try to run ../gcc-4.9.2/contrib/test_summary?
I did the first time it quit. Looked OK.
> Now, you have never posted (unless I missed something) the error in
> e2fsprog. Maybe it would be easier to analyze that error?
We have a saying about "bad pennies". I expect to see it again
shortly. ;-)
> Those sound pretty generic, but not necessarily "lesser" than your
> build machine. To me, for _LFS_ "lesser" implies i486, i586, or
> those short-lived not-quite i686 CPUs (Cyrix?). I believe that for
> LFS, all recent (for intel, P3 and newer, for AMD athlon and newer)
> x86 CPUs in 32bit mode will build for i686.
I'm taking those variables out for now. I didn't expect them to be a
problem. They'll go back for BLFS.
I investigated and convinced myself config.guess will continue to build
for an i686. So when I go forward again the environment variables will
not be a confusion factor.
I was confused because the kernel configuration is built for a Conroe.
Apparently from uname's perspective that doesn't matter.
> You discount my assertion that although a single failing test will
> cause 'make check' to report an error, it does not matter. Now that
> you are certain your scripts match the version of the book you are
I'm still keeping the "command stringing", configuration/make logs, and
package management!!! ;-) (See below)
> using, I think there is very little to be gained until you have a
> failure to build a package. Yes, it is _possible_ that you might
> eventually have to backtrack. It is also possible that you have
Being scriptified with package management that's not so hard to do.
It's staying.
> overlooked, or not been aware of, something else entirely. Bad
> memory, or transient memory problems, are the sort of things which
I'm running the machine check logger, after recent experiences. I
should know if something like that happens.
> the problem). There are also all sorts of reports that a few
> toolchain tests have failed on certain CPU models, or on certain
A buddy works for Intel on post-processing validation, PPV. He says
there was some obscure machine check on Conroes that wasn't publicized
(somebody there doesn't remember FDIV!) but M$ has programmed around.
Intel is a big contributor to the kernel--hard to believe they didn't
contribute a patch.
> kernels : I always recommend upgrading the host to the kernel you
> intend to use on the new system, if you can, but that does not solve
> the "fails on this model" failures.
I'm at 2.6.34.14, at the time chosen for being a LTS version.
> If you do not set them, then by definition they cannot contaminate
My thought exactly!
> I think the problem was probably with the more exotic options.
Not (supposed to be) using any that aren't in the book.
> then I think it is a far better use of your time to keep your software
> up to date (to reduce the attack surface) than to review the history
> of how LFS got to where it is.
My friends consider me somewhat paranoid about security as it is. I'm
very aware of "attack surfaces"--my career was in computing after all.
My handbuilt firewall has some 140 rules, for example. It is VERY
strict. And you have to admit, building our own systems, as we do,
gives us control over what we choose to allow in our attack surfaces--no
more than I must!
Part of the RoT I've learned over the years is: when updating, don't try
to jump too far. It's that ROT, not that I'm interested in the history
of LFS (though a few years back I build a 2.1 system to run on my old
486/33 because I needed it). I feel exceptionally fortunate that having
begun when I did with commercial computers and hand-made "hobbiest"
personal computers, an IMSAI, I relived/experienced pretty much the
major history of electronic computing.
> Do what you wish, and take a break if you stop enjoying it.
I am, and I will, but not yet. ;-)
> > Do you want the bash-4.2 ShellShock patch file posted? It might be
> > worth an erratum.
>
> We are unlikely to do an erratum - LFS has been using 4.3 for some
[ ! some > 2 ]
> years. But I did upload 4.2-fixes-13 in the early stages of the
> shellshock fixes, and Armin updated it to -14 for later fixes. I
> still have one or two old desktop systems which I try to keep
> semi usable.
My patchset goes up to 4.2-53. The ShellShock patches are very recent.
> Wish I had seen this before my earlier reply. Yes. 'make -k check'
> means the check will continue past the first set of errors (i.e.
> whichever directory fails), but it still reports a failure. I think
> one failure from "a lot of tests" in gcc (or binutils, or glibc) is
> not indicative of a crisis.
No, I didn't think so. OK, answer me this, since I'm NOT an automake
jockey. (Just got a book about it at Powell's by Vaughn, et al., but
whoa, way above my pay grade!) What's the difference between setting up
make to anticipate errors and having an error abort the whole make
process? Is one of the former likely to slip past by accident and turn
into one of the latter? Does gcc upstream make that sort of error?
> For testing BLFS or LFS packages I build as a user in /scratch/ken
> with a DESTDIR install to see what gets installed
Some packages don't allow for a DESTDIR--heck some aren't autotooled at
all! I've been using Ingo Bruekle's Guarded Installation Tool, "git",
with a few enhancements I "needed", since 2004 and am now quite
confident in using it properly. Since Linus appropriated the acronym, I
renamed it Package Installation Observer, pio. It's a timestamper.
> It doesn't matter _where_ you build, but certain locations imply
> historical baggage.
/usr/local is kind of "free game". All I keep in /usr/src is the
kernel.
> Compare that to many audio/video packages which do go out of their way
> to get the most out of the processor.
Never have been comfortable with Flash--it's one of those Attack
Surfaces!
> For the toolchain, the major linux "customers" are the distros. The
> main distros aim to cover as much hardware as possible with one
> binary, so using speedups that only apply to a few processors is not
> something they often choose.
Nor I, and my paradigm is KISS. I've never been attracted to the
"kitchen sink distros". If I had more time I might try Arch or Core,
but life is short!
As Arnold said, "I'll be back"
to report the error is still there or gone. Won't take too long. ;-)
--
Paul Rogers
[email protected]
http://www.xprt.net/~pgrogers/
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
--
http://www.fastmail.com - A fast, anti-spam email service.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
