[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 15:56:30 -0500 (CDT)

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 Friesenhahn
GraphicsMagick Maintainer,

reply via email to

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