On Sat, Nov 22, 2014 at 05:00:20PM -0800, Paul Rogers wrote: > Allow me to address your last point first, the scripts that I make/use: > [...] > 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. >
OK, I was just pointing out that we cannot know what is in your scripts. I will assume you have made all the changes from the previous version of the book (me, I often miss something here or there - either it blows up and is obvious, or I can go for a long time without noticing the difference. So, it always pays to review if there is any doubt. > 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. > My current scripts (probably my third or fourth major rewrite - I needed to improve my logging of what got installed - mostly fail on any non-zero return (there are a few places where I had to turn that off, for conditional commands). And I also build lfs-dev, where test failures often happen as versions change.. So, many of my test invocations end ' || true'. In other words, I do not regard a failing test, even in the toolchain, as necessarily catastrophic - for me, what matters is whether the resulting system does what I want. And if a test fails, a non-zero status is to be expected. > > 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! > It's your system, and your time. I used to think that 'perfect' test results were good. But all the tests do is check for a recurrence of past errors. And with different hardware, different things can cause tests to break (e.g. Bruce's toolchain results often look better than mine). Also, I repeat what Bruce said - for one or two errors in the tests for a toolchain package, carry on. > > 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. > Building there is ok, if somewhat unusual. It just seems like an odd place to build things which are part of the base system, and will be installed in /bin or /usr/bin. I did not pay too much attention to the files, or I would have realised it was the build tree. > > 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. > Other things can happen (heat, component failure, transient errors). A quick look at an x86_64 log for e2fsprogs-1.42.5 suggests that it uses 'CC' as the compiler, not 'CXX', so a libstdc++ ABI change seems unlikely to impact e2fsprogs. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- 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
