On Sun, Oct 25, 2015 at 10:42:38PM -0400, Michael Havens wrote: > thank you for taking the time to help. > from what you've said seems to imply I need to compile binutilities again. > so: >
That was not what I meant : First, identify what went wrong. You have gone along with my *guess* that binutils needs to be repeated (at this very early stage in chapter 5, that will probably turn out to be correct). But unless you learn to identify the *detail* of what went wrong, you will be blundering around, and likely to repeat the problem. In general, we don't take much interest in how a particular person chooses to script a build and so we are unlikely to look deeply at the details of your script. Some of it is a question of individual style, or of harmless variations from the book to suit individual circumstances (e.g. I never build in /sources because that is on a different machine, accessed over nfs, and I code the loader name in a variable so I can run tests correctly on both 32-bit x86 and x86_64), or of forcing particular CFLAGS which is *usually* harmless but apparently caused a problem for somebody in gmp in the last few weeks. So, whatever works is ok. The downside of that is that you need to understand how *your* scripts fail. And for that, you need to gather the evidence (in this case, the real error message). We (that is, those of us who write our own scripts to build LFS or parts of BLFS) have all had to pass through that stage. Unfortunately, the learning can be painful, and occasionally it might take a long time. I remember when I had to rewrite my own scripts and library functions (identifying the package's directory, space and time measurements, logging of installs) to get a new version of one of the gnu packages to pass its tests - in the end, it became clear that one of my variable names conflicted with something in the new version. I never did establish *which* variable name, but changing all of them to use a KM_ prefix (after changing all my functions to have a 'km_' prefix!) finally worked around that. And because it was so painful (a case where git bisection on the source, to identify the change which broke my build, did not work because of the need to pull in gnulib and my inability to find a way to force that to be what was used at the time of the commit to the package), I remember much of the detail. Your scripts, for the moment, are much more basic. But the point is that running a series of commands the first time you build LFS, and looking at what messages they give you, is different from tieing everything for a package with '&&' and testing $? or $PIPESTATUS. Also, you need to ensure that the script has the correct environment (for $PIPESTATUS I suspect /bin/sh needs to be bash, and you need to ensure that the "LFS" variables are set). Also please read the footer. You are top posting and (like most linux lists) we do not enjoy that. Thanks. ĸen -- Il Porcupino Nil Sodomy Est! (if you will excuse my latatian) aka "The hedgehog song" -- 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
