Building without chroot'ing

Dagmar d'Surreal no.spam at
Wed Jan 1 14:31:14 PST 2003

On Wed, 2003-01-01 at 02:59, 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.
> This is another reason for the use of the static builds and the chroot -
> the static builds are to give enough of a development base to start
> compiling things, once $LFS becomes our root, and the new things that are
> compiled in Chap 6 have the correct paths in the binaries.

Actually, if you were going to build bash and install it into a
different prefix, you woulnd't use --prefix=/mnt/lfs, you'd use
--prefix=/ and then change the value of the prefix setting in the
Makefile when you invoke the install target, like `make prefix=/mnt/lfs
install`.  Doing this avoids the problems you mention about hardcoded
paths for any package that adheres to a proper make procedure (i.e.,
*no* new files are created during the instal target).  Note that there
are a few which will fight you, so watch the output carefully (bash
won't tho).

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

More information about the lfs-support mailing list