Ch5: "Locking in" glibc, Ch6: Adjusting toolchain

Jouko Orava joorava at
Sun Jun 1 20:30:13 PDT 2003


Commands after make in Chapter 5, '"Locking in" glibc'
is exactly reversed in Chapter 6, 'Adjusting Toolchain',
again after the make command.

I suggest that the first one is modified so that the
original spec file is saved as 'specs.lfs-orig', and
the latter one simply moves it back. This eliminates
the second sed altogether, and removes the need for
a temporary file (named XX in cvs LFS).

Ch5: '"Locking in" Glibc", after the make and the comment:
echo n | mv -i $FN $FN.lfs-orig
sed -e 's@/lib/ at g' \
    -e 's@/lib/ at g' \
    $FN.lfs-orig > $FN
unset FN

Ch6: 'Adjusting toolchain', after the make:
mv -f $FN.lfs-orig $FN
unset FN

I replaced SPECFILE with FN since SPECFILE does not "sound"
like a temporary variable, and I have a nagging feeling
SPECFILE modifies behaviour for some packages.
A quick Google only turned up VMI_SPECFILE and other
_SPECFILEs, though. Although SF might be a more logical
choice, $SF is much more prone to typos than $FN.
Anyway, you are welcome to change if you disagree!

In Chapter 5, we want to make sure "specs.lfs-orig" is
never overwritten, as it would break the build totally
later on. The 'echo n | mv -i ...' never overwrites.

In Chapter 6, we expect the overwritten file to exist;
the -f flag for mv removes the error message.

Rerunning these does not break anything, but will
produce extra output. (For chapter 5, the automatically
refused overwrite message, and for chapter 6, file
not found error.)

(For those maintaining build scripts, I suggest using
 a for loop for FN, and checking for file existence
 before operations. I'm not sure if anyone ever built
 more than one gcc for /stage1, but it's not inconceivable.
 I like to be robust myself, and even use a couple of
 strategically placed 'fgrep -q's to make sure the
 file contents are what they should be. Paranoid? ;)

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list