[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiling into chroot

From: Alon Bar-Lev
Subject: Re: Compiling into chroot
Date: Thu, 12 Jun 2008 23:12:39 +0300

On 6/12/08, Bob Friesenhahn <address@hidden> wrote:
>  There are three ways of looking at this issue.  One is to prepare the files
> differently so that they "just work" in the chroot environment (requires the
> FAKEROOT when files are prepared).  The second way is to do something
> special so that already prepared files "still work" in the chroot
> environment (requires the FAKEROOT when files are used under chroot).  The
> third way is to edit/update the .la files so that they work in the new root.
>  The first and second ways seem to cause runtime overhead for all libtool
> users and are not completely portable since build tools may embed paths to
> source files, object files, or libraries in the built objects and libraries.
>  There is quite a bit to keep track of so new bugs may be added.

Because of this configure --prefix=/ is used, so embedded paths will
be relative to root and not directory in host system.
So the only issue is with libtool.

>  The third way is similar to the first way except that it requires an extra
> step from the user.  As it turns out, libtool already supports a "last step"
> (--mode=finish) which could be used to fix up any paths as well as do any
> platform-specific actions.  Libtool would have to know that paths need to be
> corrected.  This would need to be executed from within the chroot
> environment.  The path correction could be computed based on the difference
> between the current path and the path in the .la file.  It may be that some
> existing platform-specific actions (e.g. ranlib, ldconfig) might fail in the
> chroot environment since the user has not made it complete enough.
>  Since the libtool project is a volunteer project, it does not "take
> requests" unless a maintainer volunteers to do the work.  The best path
> forward is for a interested volunteer to perform the necessary edits, prove
> that they work, and submit a patch.  There is the risk that it will be
> decided that the changes are too invasive or too risky and the patch might
> not be accepted.

We all volunteers... and before we do work for a project, we need to
know that it is not for nothing. But usually project maintainers can
do these stuff in less effort and better quality.

>  The FAKEROOT proposal sounds similar to DESTDIR (implemented in Automake)
> except that it may require many changes in libtool vs very little required
> change for DESTDIR.

This is the simplest, as execution of commands within the chroot is
impossible. As it may be cross compile and target is not operational.

As far as I understand, you can add FAKEROOT into each path variable
read from .la files, and removed before writing the .la files. Also
removed from all operations during the finish stage.

But as libtool script is so complex it is very difficult to provide a
solution to outsiders.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]