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 <[EMAIL PROTECTED]> 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
======================================
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool