On Sun, Nov 23, 2014 at 12:43:05PM -0800, Paul Rogers wrote: > > From: Ken Moffat <[email protected]> > > > > OK, I was just pointing out that we cannot know what is in your > > Yes, I don't post them only because I don't want to waste your time > trying to understand them.
That's fine. I was only pointing out that attempting to provide useful responses to "e2fsprogs did not build" is total guesswork. > > 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 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. > > > time without noticing the difference. So, it always pays to review if > > there is any doubt. > > Been through twice, starting again. ;-) > Sometimes works. > > Also, I repeat what Bruce said - for one or two errors in the tests > > for a toolchain package, carry on. > > Well, I don't know about the abi_check. I thought because the make > scripts dropped out the upstream folk didn't think that was a > recoverable error. You think it's negligible? > 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. > > 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 > > I use /usr/local/src for all my building, LFS/BLFS/other, and I like to > keep all of it together. LSB isn't strict about what goes there. > It doesn't actually matter where you build. Nowadays, I mostly build BLFS (as root throughout) in /scratch because it doesn't get backed up and I do not wish to backup the transient build directories. For LFS I build chapter 5 in /mnt/lfs/building because my sources are on an nfs mount. For testing BLFS or LFS packages I build as a user in /scratch/ken with a DESTDIR install to see what gets installed [ used to use ~/ but I don't need the large and slow backups for e.g. firefox or libreoffice ], and the same for kernel upgrades and for testing development kernels. For the book(s) I also do a real install, and use the package (either see if it works for what _I_ do, or else see if it still acts as a valid dependency for whichever other packages need it. It doesn't matter _where_ you build, but certain locations imply historical baggage. > > 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. > > Maybe not, but eventually it'd bite me. So what about my root > environment variables? Could it be those? Is there some (other) way I > can ensure it builds for any i686? (Expect the compressors & encrypters > would use the most advanced enhanced instructions they can find, unless > told not to.) If you use binaries, a change can certainly impact you. If the ABI did indeed change (google found some hits which implied that it probably did during the 4.7 series), anything compiled using this version either works, or like the failing test it relies on behaviour that has changed. If _common_ applications fall into that category, google usually knows about them after the change begins to show up in distros. So in this case I do not think there is anything to worry about. For encrypters, you are in BLFS territory. For gzip, bz2, xz (or lzma) I think they will mostly use C code, and the compiler will decide how to convert that to assembler. Perhaps gcc does recognize some optimizations, but probably only if you force it to compile for a specific machine variant. Compare that to many audio/video packages which do go out of their way to get the most out of the processor. Certainly, zip/unzip can use assembler - but it's generic "i386" or "i686" instructions. 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. ĸ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
