chapter 6.16: configure: error: =?iso-8859-1?q?in=09=60/sources/gcc-build/i686-pc-linux-gnu/libgcc=27=3A?=, ... C preprocessor "/lib/cpp" fails sanity check

Neal Murphy neal.p.murphy at alum.wpi.edu
Wed May 26 12:50:26 PDT 2010


On Wednesday 26 May 2010 13:19:54 Bruce Dubbs wrote:
> Neal Murphy wrote:
> > On Wednesday 26 May 2010 08:33:20 linux fan wrote:
> >> On 5/26/10, Simon Geard <delgarde at ihug.co.nz> wrote:
> >>> I can't really see how things can be improved (short of blinking red
> >>> text on *every* page), but it does seem like half the problems we deal
> >>> with are from people not following it. Are people not even reading that
> >>> entire "General Compilation Instructions" page, and skipping straight
> >>> to the packages?
> >>
> >> The important note #1 in ch 5.3 is clear.
> >> However, "General Compilation Instructions"  never specifies the flow
> >> of events expected to follow:
> >>
> >> 1 - make sure $LFS is set to the target directory (export LFS=/mnt/lfs)
> >> 2 - change directory to $LFS/sources
> >> 3 - unpack the package tarball
> >> 4 - change directory to the unpacked directory created by tar
> >> 5 - follow package build and install instructions
> >> 6 - change directory to $LFS/sources
> >> 7 - remove the unpacked directory created by tar
>
> We don't have it in a list, but it is in Section 5.3.  I even put in a
> note as the very first thing in Binutils:
>
>   Note
>
> Go back and re-read the notes in the previous section. Understanding the
> notes labeled important will save you a lot of problems later.
>
> I guess I'll need to reemphasize some more.  :(

Allow me to present a couple definitions. First, a 'user guide' is a documnet written in plain language prose that guides the user through some task or operation. Second, a 'reference manual' is a document written using less prose and more 'techno-ese' to provide all the syntax needed to perform variations of a task or operation.

From a "user guide" viewpoint, I think the existing emphasis is great; the book is well-written. From a 'reference manual' viewpoint, the details and syntaces can be, mmm, hard to see.

Recall the old adage, "Tell 'em what you're going to tell 'em. Tell 'em. Then tell 'em what you told 'em." Perhaps what Linux Fan and I are trying to say is that the LFS book could be improved by adding that list to the bottom of the "General Compilation Instructions". Think of it as a terse summary of the steps to be taken. Then put a link directly to that list on each package build page. Yes, it will be repetitious. But the human eye will ignore it it if it's not needed.

Something like:

Summary of general package build operations
  a. Pre-build steps
     1. set $LFS equal to the target directory
     2. cd to $LFS/sources
     3. unpack the package archive
     4. cd to the package directory
  b. Follow the package build and install instructions.
  c. Post-build steps
     1. change directory to $LFS/sources
     2. remove the unpacked directory created by tar
     3. remove the build directory if created, unless told not to

There it is in a nutshell: a handy reference reminder.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20100526/950b4863/attachment.html>


More information about the lfs-support mailing list