On Thu, 12 Jun 2008, Alon Bar-Lev wrote:
This is the simplest, as execution of commands within the chroot is
impossible. As it may be cross compile and target is not operational.
Commands may be executed if the chroot environment is sufficiently updated
to make it possible.
How? If this is for different CPU?
I have the same issue with cross compile to mips, I compile initramfs.
Do you mean that you need a libtool something to run on my embedded
initramfs to fix up the mess at runtime?
Cross-compile is a special case. I can see that you would need to run
libtool's fix-up script using the native OS and CPU. That means my
suggestion to compute the fixed paths automatically would not work for
cross-compile.
How does this mesh with libltdl (which also reads .la files) and test
suites? It seems that libltdl would also need to know about FAKEROOT, which
results in every application using libltdl responding to FAKEROOT. There
may be additional security issues here similar to LD_LIBRARY_PATH, but worse
since the compromised application could setenv FAKEROOT before a module is
loaded and cause a compromised module/library to be loaded.
I don't understand!
If all pathes within the .la files are relative to the FAKEROOT, the
libltdl which runs within the chroot environment will find the files
exactly where .la files reference to.
All the work should be done so that within the chroot environment all
files will be as if they were compiled within it.
The libltdl code doesn't know if it is executed in a chrooted
environment. The FAKEROOT option can be used for purposes other than
cross-compile so it can be expected that if the build is not a
cross-compile then libltdl needs to be able to work (to support
testing), and therefore needs to respect FAKEROOT.
Besides cross compile, a use of a chrooted environment is to detect
use of files which are not currently resident in that environment. It
is a poor-man's way to decide if the build is likely to work on
someone else's machine without testing on another machine.
DESTDIR users may also have a desire to "fix up" the .la files but
without desire for the FAKEROOT features.
It seems that there are many descriptions of this elephant.
Bob
======================================
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
