On Sat, Nov 22, 2014 at 11:55:50PM -0800, Paul Rogers wrote: > > I want the binaries to be built to run on lesser hardware than what I > build on, of course, and some configures in the past have taken their > -march from the hardware I build on. I don't want that to be a > requirement! Consequently in the BLFS builds especially I have the > following in root's environment and all BLFS scripts using configure > specify CTARGET: > > export CHOST="i686-pc-linux-gnu" > > export CTARGET="i686-pc-linux-gnu" > > export CFLAGS="-march=i686" > > export CXXFLAGS="-march=i686" >
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. For BLFS, where some packages take advantage of CPU facilities, that statement does not hold. And I cannot forcing i686 causing any problem for you (unless you were to try it on something less than i686). 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 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 overlooked, or not been aware of, something else entirely. Bad memory, or transient memory problems, are the sort of things which come to mind. And if you get transient memory problems then I think either sunspots or solar flares are the sort of things we usually blame, after spending a couple of days totally failing to replicate the problem). There are also all sorts of reports that a few toolchain tests have failed on certain CPU models, or on certain 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 remember admonitions from 6.1 about CFLAGS/CXXFLAGS, so those are > specifically unset when building binutils/glibc/gcc. I looked, but 7.2 > doesn't have the same admonitions. Are they still an issue? Can they > be contaminating my build now? If you do not set them, then by definition they cannot contaminate your build. For my own builds (i.e. when I am *not* trying to test every last detail of LFS for a release) I pass -O2 to those flags. Again, unlikely to make a difference to LFS packages, except that it removes debug information. I think the problem was probably with the more exotic options. Also, if you are either running services which are publically accessible, or have real users, or if you use a desktop connected to the internet, 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. But it's your time and your systems. I'm currently diverting myself to using qemu to review how some other distros, and even FreeBSD, do some things. So I do understand the concept of doing things because they are interesting - and also how to make incorrect assumptions, to have to backtrack, and how to spend a lot of frustrating time trying possible solutions which turn out to make no difference at all. My choice, but I cannot _lightly_ recommend this approach. Do what you wish, and take a break if you stop enjoying it. ĸ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
