If you run into a problem while working through this book, you should first check the FAQ at http://www.linuxfromscratch.org/faq/ -- often your question is already answered there. If it is not, you should try to find the source of the problem. The following hint might give you some ideas for your troubleshooting: http://www.linuxfromscratch.org/hints/downloads/files/errors.txt.
If all that fails, you will find that most people on IRC and the mailing lists (see the section called “Resources”) are willing to help you. But to assist them in diagnosing and solving your problem, please include all relevant information in your request for help.
Apart from a brief explanation of the problem you're having, the essential things to include in your request are:
the version of the book you are using (being 5.1-pre2),
the host distribution and version you are using to create LFS,
the package or section giving you problems,
the exact error message or symptom you are receiving,
whether you have deviated from the book at all.
(Note that saying that you've deviated from the book doesn't mean that we won't help you. After all, LFS is about choice. It'll just help us to see other possible causes of your problem.)
When something goes wrong during the stage where the configure script is run, look through the config.log file. This file may contain errors encountered during configure which weren't printed to the screen. Include those relevant lines if you decide to ask for help.
To help us find the cause of the problem, both screen output and the contents of various files are useful. The screen output from both the ./configure script and the make run can be useful. Don't blindly include the whole thing but, on the other hand, don't include too little. As an example, here is some screen output from make:
gcc -DALIASPATH=\"/mnt/lfs/usr/share/locale:.\" -DLOCALEDIR=\"/mnt/lfs/usr/share/locale\" -DLIBDIR=\"/mnt/lfs/usr/lib\" -DINCLUDEDIR=\"/mnt/lfs/usr/include\" -DHAVE_CONFIG_H -I. -I. -g -O2 -c getopt1.c gcc -g -O2 -static -o make ar.o arscan.o commands.o dir.o expand.o file.o function.o getopt.o implicit.o job.o main.o misc.o read.o remake.o rule.o signame.o variable.o vpath.o default.o remote-stub.o version.o opt1.o -lutil job.o: In function `load_too_high': /lfs/tmp/make-3.79.1/job.c:1565: undefined reference to `getloadavg' collect2: ld returned 1 exit status make[2]: *** [make] Error 1 make[2]: Leaving directory `/lfs/tmp/make-3.79.1' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/lfs/tmp/make-3.79.1' make: *** [all-recursive-am] Error 2
In this case, many people just include the bottom section where it says:
make [2]: *** [make] Error 1
and onwards. This isn't enough for us to diagnose the problem because it only tells us that something went wrong, not what went wrong. The whole section, as in the example above, is what should be included to be helpful, because it includes the command that was executed and the command's error message(s).
An excellent article on asking for help on the Internet in general has been written by Eric S. Raymond. It is available online at http://catb.org/~esr/faqs/smart-questions.html. Read and follow the hints in that document and you are much more likely to get a response to start with and also to get the help you actually need.
Many packages provide a test suite which, depending on the importance of the package, we may encourage you to run. Sometimes packages will generate false or expected failures. If you encounter these, you can check the LFS Wiki page at http://wiki.linuxfromscratch.org/ to see whether we have already noted and investigated them. If we already know about them, then usually there is no need to be concerned.