[Top][All Lists]

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

Re: Compiling into chroot

From: Bob Friesenhahn
Subject: Re: Compiling into chroot
Date: Thu, 12 Jun 2008 14:56:35 -0500 (CDT)

On Thu, 12 Jun 2008, Richard Purdie wrote:

On Thu, 2008-06-12 at 22:03 +0300, Alon Bar-Lev wrote:
On 6/12/08, Roumen Petrov <address@hidden> wrote:
 It look like an enhancement request. libtool to obey as example
FAKEROOT=/tmp/device-root and to look first in $FAKEROOT/path1
 , ... and $FAKEROOT/pathN and later in /path1,... and /pathN .

This what I had in mind.
It also should append the FAKEROOT to pathes read from .la files.

You mean prepend :)

This is the same issue as the sysroot one I've previously mentioned.
OpenEmbedded currently hacks the .la files in its staging area to
include the sysroot prefix but this means you can't use staging as a
chroot. I've not had time to look into doing anything about this feature
but I would love to see it!

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.

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.

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.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

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