Allow me to address your last point first, the scripts that I make/use:

> Also, you said earlier that you were using your own package manager,
> or perhaps just your own scripts.  The great thing about writing our
> own scripts is that when they break, we get to keep all the pieces.

As I mentioned initially, this is my fifth LFS build, these scripts have
been used many times, just minor mods as are in the book, version to
version.  There is one function that is very, very close to just what's
in the book.  I'm very, very careful to not depart from what works in
new and original ways.  My package manager uses before/after snapshots,
totally out of the way during install.

I registered my first LFS build in 2004.  I've seen some of the stuff
you get on the mailing list.  You're right to be a little cautious, even
if abi_check failures aren't a common problem.  I'll take responsibility
for my scripts, but they DO work on the KISS principle. [Heck, that's
why I use LFS!!! ;-) ]

> > I notice your test cases were build for x86_64, mine for i686.  As I
> > said, I did a C&P into a wrapper script, but my error causes the
> > "make check" to drop out.  That alone makes it seem pretty
> > important.
>
> By "drop out" you mean, "only got this far, then stopped", or "failed
> after reporting all the results ?"  The latter sounds like normal
> behaviour for non-ignored errors.

I use this: (make -k check 2>&1 | tee log.check && exit $PIPESTATUS) &&
The $PIPESTATUS, with "#!/bin/bash -e" means if the make produces an
error code, bash drops the script, even if tee produces a 0.  That's
what's happening--make check is erroring out, leaving a log file.

> I will also point out that 7.2 was something like 2 years ago and few
> people here are likely to remember any details.  On "one unexpected
> failure" I agree with Bruce : Carry on.

I would have, but if the make check errors out, that's not a normal
unexpected error.  make really wanted to quit!

> But two more comments below :
>
> > Using /usr/local/src/gcc-4.7.1/libstdc++-v3/testsuite/config
> > /default.exp$
>
> /usr/local ??

I have chosen to do all my development in /usr/local/src.  That's OK
with LSB, isn't it?  Once the target FS is created, that's where I
move my scripts, tarballs, patches directories.  Is that any problem?
Never has been.

> If you are following the book (and the references to /usr/local in
> what you pasted make me doubt that), people _might_ be able to help on

Not rigidly, no, but in all important respects.  (Look, I'm not out to
waste my time or yours, and my profrssional career was in computing and
computing management, beginning as a programmer in 1966.)

> the e2fsprogs issue.  But only if you explain the problem. Saying it
> "died in a mysterious way" is not a useful error report.

The way it failed made me suspect the compiler.  I need a reliable
compiler before wasting time with e2fsprogs.

The question is why the ABI check is failing.  I've seen that libgomp
can make abi_check fail, but we don't disable it and they all pass.

                === libgomp Summary ===
# of expected passes            1247
-- 
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 - Or how I learned to stop worrying and
                          love email again

-- 
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

Reply via email to