[lfs-support] Greetings and first two questions

Firerat firer4t at googlemail.com
Mon Jan 30 18:31:26 PST 2012

On 31 January 2012 00:31, rafe_b <rafeb at speakeasy.net> wrote:
> Hello All -- just starting with LFS and learning a lot so far.
> I have a couple of questions as I start the builds in Ch. 5.
> 1. many commands have file arguments with relative
> paths, eg. the very first two commands in Sec. 5.5.1:
> tar -jxf ../mpfr-3.1.0.tar.bz2
> mv -v mpfr-3.1.0 mpfr
> There's a Note in Sec. 5.3 that says I should be in the
> 'sources' directory but then the above commands
> wouldn't be right.  So where should I be when I execute
> these commands?
you should untar your target src, cd into that dir and then run the commands
assuming you are in the dir your tarballs/patches are

    tar xf gcc-<version>.tar.<ext>
    cd  gcc-<version>
    < insert book commands >

Personally I create a build dir separate from the source (1), and
symlink the source files
( Don't worry about this if it doesn't make sense, I've been using the
cli for a good while )

    mkdir $LFS/build
    cd $LFS/build
    ln -s ../source/* .  # note the '.' at the end of that, . is the
current dir
# you could instead do ln -s $LFS/source/*
# BUT you would need to recreate your symlinks once you enter the chroot
# the symlinks would point to , for instance,
/mnt/lfs/source/<target> , in the chroot you need it to point to
/source/<target> or ../source/<target>  relative to the build dir
Hope that doesn't create too much confusion

You would then untar your gcc source, cd into it and run the book commands

the ../mpfr-3.1.0.tar.bz2 points to the symlink , which will then
point to the actual tarball ( assuming source and build dir are both
on the root of your lfs partition )

it just makes life a little simpler when it comes to 'cleaning up',
i.e. I can just delete the build dir keeping hold of the original

rm -r /build

is easier  *and* safer than

find /source/* -maxdepth 1 -type d -exec rm -rf {} ';'
# Note, if you miss off the /* you will end up deleting  /source
# a little safer
find /source/* -maxdepth 1 -type d -exec echo rm -rf {} ';'
# by putting the echo in you can review what is going to be done, and
then repeat with <UpArrow> and adding a pipe to a shell on the end,
find /source/* -maxdepth 1 -type d -exec echo rm -rf {} ';' | sh

of course, you could delete each src dir as and when you finish with
it ( and you should certainly do that with binutils and gcc as you do
two passes, I'm just lazy with that kind of thing )
(1) actually, I'm so lazy (2) I create another depth, e.g
     install -d $LFS/build/binutilspass1 # like doing .. mkdir
$LFS/build && mkdir $LFS/build/binutilspass1
this way I need not worry about hangovers with binutils and gcc
(2) actually, I'm so lazy I write scripts to do it all for me..
but try to avoid using automated solutions until you have gone through
the book manually, at least once or twice

> 2. The issue in the previous item isn't insurmountable
> in most cases, but it gets critical for the first 'patch'
> command of Sec. 5.5.1, to wit:
> patch -Np1 -i ../gcc-4.6.1-cross_compile-1.patch
> Being a newb to the 'patch' utility, I have to guess
> that the patchfile must be positioned properly relative
> to the corresponding source files -- but in this case I
> can't figure out which source directory they're in.
> It could be one of {mpfr, gmp, mpc} or the parent
> of these.  Again, where should I be when running
> this patch command?
the patches are crafted such that they are relative to the root of the
source ( after stripping the leading path in the patch with the -p
patch --help , for some detail ( man patch and/or info patch, will get
some more )

> [There are two files being patched, but they
> are not unique to any one of these three
> directories -- 'configure' appears in all three,
> and 'configure.ac' appears in two out of three.]
It is only patching  ./configure and ./configure.ac ( relative to the
root of the gcc src )
the patch is for gcc, not  mpfr, gmp or mpc
Talented, Witty And Thoughtful .. is how most describe me.

More information about the lfs-support mailing list