lfs-book/chapter02/askforhelp.xml

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

<para>If you have a problem while using this book, you'll find that most
of the people on Internet Relay Chat (IRC) and the mailing lists will be
willing to help you.  You can find a list of the LFS mailing lists in
<xref linkend="ch01-maillists"/>.  To assist us in helping though, you should
make sure that you have as much relevant information as you can
available.  This will assist in diagnosing and solving your problem.
This part of the book will guide you as to which sort of information
will be useful.</para>

<sect2>
<title>Basic Information</title>
 
<para>First of all we need a brief explanation of the problem.
Essential things to include are:</para>

<itemizedlist>
<listitem><para>The version of the book you are using, which is &version;</para></listitem>
<listitem><para>Which package or section you are having problems with</para></listitem>
<listitem><para>What the exact error message or symptom you are receiving is</para></listitem>
<listitem><para>If 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 all about choice.  It'll just
help us to see the possible other 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>

</sect2>

</sect1>