Building without chroot'ing

Tushar Teredesai tushar at linuxfromscratch.org
Wed Jan 1 06:24:42 PST 2003


J_Man wrote:

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

-- 
Tushar Teredesai
   http://www.linuxfromscratch.org/~tushar/
   http://www.geocities.com/tushar/


-- 
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 mailing list