Re: Compiling into chroot

[Roumen Petrov]

Bernd Jendrissek wrote:
> On Sat, Jun 14, 2008 at 9:59 AM, Alon Bar-Lev <address@hidden> wrote:
> > Building packages into chroot is more and more common, live-cd,
> > live-usb, initramfs, embedded, vservers etc...
> >
> > A lot of packages use libtool, so using the standard gnu build for
> > chroot environment, in order to build packages without change in the
> > package is important.
> > ./configure --prefix=/
> > make install DESTDIR=/tmp/myroot
> >
> > As far as I know libtool is the only tool that needs fixups or
> > workaround.
>
> I've never gotten around to actually doing this, but I wonder if
> inverting the "standard-ness" of paths could help.  You could set up a
> chroot environment that you use for building, where you have your
> *build* tools (compiler, linker, etc.) as /unexpected/location/bin/gcc
> etc., and install directly (without DESTDIR) into the "root" directory
> which has the sticky flag (like /tmp).  It would mean that you never
> test proper DESTDIR support though.

I don't think that "compiling into chroot" is the right subject.
As I understand host system is accessible in build system under a prefix 
"path_to_host_system". I don't think that only libtool is affected. 
During configure time autoconf macros has to detect presence of headers, 
functions, libraries in host system. At make time libtool has to compile 
and link against files in host system.

What about a new configure flag --host-prefix.
./configure --prefix=/usr ... --host=... --host-prefix=/path_to_host_system

In this case compiler has to prefix all include path by 
/path_to_host_system. Also note cross-compiler search path.
The linked has to search in directories prefixed by same path, but rpath 
in shared libraries has to omit this prefix. Also note default library 
search-path (gnu linux - /path_to_host_system/etc/ld.so.conf).

Roumen