On Mon, Aug 06, 2012 at 06:37:07PM +0200, firstname.lastname@example.org wrote:
> Paul Hartman <email@example.com> [12-08-06 17:36]:
> > On Mon, Aug 6, 2012 at 8:01 AM, <firstname.lastname@example.org> wrote:
> > > Hi,
> > >
> > > I am asking, because I found not only one description of somehow
> > > complicated setups to compile a distribution (namely gentoo) for a
> > > platform "A" (Beaglebone TI OMAP4) on that platform with distcc to
> > > speedup things or with emulated chroot environments based on qemu...
> > >
> > > I thought it would be the easiest to compile the whole stuff on a host
> > > system "B" with a crosscompilation toolchain...but may be I have
> > > overlooked something important...
> > Seems the best way to me, too.
> > > So - is there any logical reason, which prevents the process of the
> > > compilation of a complete distribution/rootfs/boot-mechanism for
> > > a platform "A" on a hostsystem of the platform "B" if the cross
> > > compilation toolchain is already installed on "B" and no emulated
> > > environment is wanted?
> > So you want to "install" the packages into a virtual filesystem image
> > on the compiler machine to create a whole disk image for the target,
> > basically? Hmmm. Maybe something like Scratchbox can help with this.
> Hi Paul,
> ...yes, exactly. But theproblem remains...is there a logical reason,
> which renders this attempt useless ?
Crosscompilation is the preffered way, but there can be a lot of
problems with it . The cross-toolchain isn't a problem, gennto has a
nice tool called crossdev that will generate it for you and with a bit
of env. variables and make.conf tweaks, you can easily do cross-compile
emerges into a specific sysroot (gentoo has nice documentation at )
The problem is usually with build systems that don't take
croos-compilation into account: things like getting paths wrong
(including the path to the root of your croscompiled stuff or using
paths in your host system, (older libtool used to generate .la files
with paths in your host system)), using information from your life
system instead of the target system, not correctly handling cases where,
as part of the installation, tools are compiled that are then directly
executed. Most build systems have ways to correctly express these
things, but authors often get them wrong etc...
Then there are cases where some post-installation steps are required to
be run in the target system (remeber those "Updating desktop mime
database " or "Updating shared mime info database" messages after most
desktop apps ?) that usually require executing the installed programs,
which means that either a host version has to be compiled (which can
correctly work with stuff in the targe root directory) or they have to
be somehow started on the first boot of the target system.
Because of this, doing it in an emulated enviroment or on the actual
device makes most of these problems go away. So if somebody doesn't
have time to sort out these cross compilation problems but doesn't mind
if the installation runs few times longer (but without problems), its
better for them...
I last did a cross compiled install of gentoo about two years ago,
mostly it was without any problems, though there were some problematic
packages (IIRC python used to be a problematic one, not sure how it is now).
Recently I have done a few "emulated root" installs and they went
absolutely without any problems (at least as far the 'compile packages
and get a rootfs) step is concerned... getting things to run correctly
on an embedded device without any display etc has its own challenges