lfs-book-zh_CN/chapter02/askforhelp.xml

<sect1 id="ch02-askforhelp">
<title>How to ask for help</title>
<?dbhtml filename="askforhelp.html" dir="chapter02"?>

<para>If you encounter a problem while using this book, and your problem 
is not listed in the FAQ, you will find that most of the people on Internet 
Relay Chat (IRC) and on the mailing lists are willing to help you. (An 
overview of the LFS mailing lists can be found in 
<xref linkend="ch01-maillists"/>.) To assist us in diagnosing and solving
your problem, include as much relevant information as possible in your
request for help.</para>

<sect2>
<title>Things to mention</title>
 
<para>Apart from a brief explanation of the problem you're having, the
essential things to include in your request are:</para>

<itemizedlist>
<listitem><para>the version of the book you are using (being &version;),</para></listitem>
<listitem><para>the package or section you are having problems with,</para></listitem>
<listitem><para>the exact error message or symptom you are receiving,</para></listitem>
<listitem><para>whether you have deviated from the book at all.</para></listitem>
</itemizedlist>

<para>(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.)</para>

</sect2>

<sect2>
<title>Configure problems</title>

<para>When something goes wrong during the stage where the configure
script is run, look at the last lines of the
<filename>config.log</filename>. This file contains possible errors
encountered during configure which aren't always printed to the screen.
Include those relevant lines if you decide to ask for help.</para>

</sect2>

<sect2>
<title>Compile problems</title>

<para>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 when make is 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:</para>

<para><screen>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</screen></para>

<para>In this case, many people just include the bottom section where it
says <screen>make [2]: *** [make] Error 1</screen> and onwards.  This
isn't enough for us to diagnose the problem because it only tells us
that <emphasis>something</emphasis> went wrong, not
<emphasis>what</emphasis> went wrong.  The whole section as
quoted above is what should be included to be helpful, because it
includes the command that was executed and the command's error
message(s).</para>

<para>An excellent article on asking for help on the Internet in general
has been written by Eric S. Raymond.  It is available online at <ulink
url="http://www.tuxedo.org/~esr/faqs/smart-questions.html"/>.
Read and follow the hints in this document and you are much more likely
to get a response to start with and also to get the help you actually
need.</para>

</sect2>

</sect1>