|
From: | Roumen Petrov |
Subject: | Re: Compiling into chroot |
Date: | Fri, 27 Jun 2008 00:03:57 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080329 SeaMonkey/1.1.9 |
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_systemIn 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
[Prev in Thread] | Current Thread | [Next in Thread] |