Bernd Jendrissek wrote:
On Sat, Jun 14, 2008 at 9:59 AM, Alon Bar-Lev <[EMAIL PROTECTED]> 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
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
