LFS Version SVN-20060501 - GCC-4.0.3 - compilation fails

Dan Nicholson dbn.lists at gmail.com
Sat May 20 08:20:09 PDT 2006

On 5/20/06, Mag. Leonhard Landrock <1977-Hamlet at gmx.at> wrote:
> 58.) GCC-4.0.3
>     cd /sources
>     cd ./gcc-4.0.3
> > If you're scripting, you have to be very careful.  You need to know
> > that the script will continue unless you have some sort of error
> > handling scheme.  If you don't a crucial step might not have worked.
> > This could lead to a bizarre error later like the one you're
> > receiving.

OK.  So, it seems that you are pseudo-scripting.  Do you just copy and
paste the commands from the text file to the shell?  The important
thing here is that you have to check that each command exited
successfully.  The book is written such that all commands are
successful, and I can confirm this because I (and many others) run
scripts that would bomb if this wasn't the case.  Well, there are a
few special cases like running testsuites, but most every command
should be successful.

So, it's important that you don't start a command before knowing that
the previous one didn't fail.  This might not be the cause of your
problems, but I'm stumped at this point.  A few quick pointers:

1. The variable $? contains the exit status of the previous run
command.  So, if it's not clear that a command failed, run `echo $?'.
If it's not 0, something's gone wrong.

2. If you're going to chain commands together, know that the next
command will run regardless of what happened in the previous command.
The way to change this behavior is to add && between commands.  So,
for "./configure && make", make won't run unless configure was

3. It helps to log the output.  The easiest way to do this is to
redirect all the output to a log file.

./configure > mylog.log 2>&1
{ make && make install; } >> mylog.log 2>&1

That still allows you to check the output status with `echo $?'.  You
can also pipe the output to the program tee, but exit status is
tougher to test there.  Whenevery you build a pipeline (cmd1 | cmd2),
you have to check the array variable PIPESTATUS which holds the exit
status of all commands in the pipe.  `echo ${PIPESTATUS[*]}'.

<snip output of script and commands>

Everything looked fine as far as setup, symlinks, etc.

> > > Might it be of any use to post this log?
> >
> > Not yet.  It would be beneficial for you to search through the log for
> > "Error" or "ERROR" or some variant.  Make sure that your problem
> > didn't actually start much earlier.

See above about logging the output of commands.  Combined with
checking exit status, you might be able to see an error along the way.
 Keep in mind that any error can be the fatal error.

> > http://www.linuxfromscratch.org/livecd/
> Well, if there is no other way, I will try that. Nevertheless I still hope
> that tere is a chance to find out what is wrong with my build system.
> Probably I did something wrong. But how to find out what?

Not to pick on you, but often operator error is the cause of these
kinds of errors.  Not that the book is bug-free.  Sometimes the source
of your errors are hard to track down.  Look at your pseudo-script and
check it very carefully for typos.

> Note: I had didn't do all the test of the packages within the chapter 5 as in
> the beginning it often says, that a check is not mandatory: "Compilation is
> now complete.

The Ch. 5 testsuites won't tell you much.  I never run them.  However,
if something is seriously broken, like gcc, running the testsuite
would probably show a lot of failures.  Unfortunately, Ch. 5 is very
influenced by the host system, so you can't really be certain about

My hunch is that you have a typo somewhere in your commands.  If
you're absolutely certain that this isn't the case, try building from
the LiveCD.  And keep in mind that the first build is the hardest.  It
gets easier every time you do it.


More information about the lfs-support mailing list