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

Mag. Leonhard Landrock 1977-Hamlet at gmx.at
Sun May 21 02:04:58 PDT 2006


Am Samstag, 20. Mai 2006 17:20 schrieb Dan Nicholson:
>
> OK.  So, it seems that you are pseudo-scripting.  Do you just copy and
> paste the commands from the text file to the shell?

Well, I copy and paste the commands from the LFS book in to the shell and 
afterwards in my personal log file.

After a reboot, when I have to become user "lfs" for example I just took the 
commands from my personal log file.

> 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
> successful.
>
> 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[*]}'.

OK, till now I just checked the output on the console.

> > > > 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.

Well, I just logged the commands I entered. But when I got some error reported 
(within a "make test") I asked on this list on what to do.

> 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.

Well, as I said above, I copy-and-pasted the commands out of the LFS book.

> 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.

Most likely that I take a new start with the LiveCD.

Thanks for all the help so far,
Leonhard.



More information about the lfs-support mailing list