Re: Compiling into chroot

[Bob Friesenhahn]

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
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/