Building without chroot'ing
tushar at linuxfromscratch.org
Wed Jan 1 06:24:42 PST 2003
>I'm honestly surprised noone's responded to this one yet. That is part of
>the reason for the chroot. However, there is more to it than just that.
>The other part is, many packages will hard code paths into their binaries
>according to the --prefix they are compiled with. So, for example, say we
>compile bash with --prefix=/mnt/lfs. When we try to boot into the new
>LFS, then bash will be looking for it's /etc/profile as
>/mnt/lfs/etc/profile, which, of course, won't exist on the new LFS system.
>Hope this explanation was clear enough - it's not 100% accurate, because I
>don't think Bash itself would do what I am suggesting, but many other
>packages would suffer from this type of situation.
Only few packages like gcc hardcode paths. Anyways, there is the DESTDIR
alternative to get around that. Most of the packages can be compiled
with ./configure --prefix=/usr && make && make DESTDIR=$LFS install, and
they won't hardcode $LFS in the binaries.
The main reason for the static build is so that there is no
contamination from the host env. But if you are already building from an
identical LFS, there is no need to even go as far as compiling Ch. 6.
Why not just make a tarball of the current installation, untar it over
the new partition, make a few configuration changes and adjust the boot
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-support' in the subject header of the message
More information about the lfs-support