Re: cross-compiling Debian packages
On Thu, Mar 09, 2006 at 10:24:58PM +0100, Peter Kourzanov wrote:
> To continue the "./configure in debian/rules" thread...
debian-devel is probably way too large audience, and will attract
people not interested in crosscompiling/embedded on making
unconstructive comments. lets move these threads to
debian-embedded@lists.debian.org, ok?
> Can anyone tell me what is the factual difference between a cross- and a
> native-build?
> I am aware only of an obvious limitation that a cross package build
> system can not rely
> on the cross-compiled binaries generated in the process (coreutils comes
> readily as
> an example)...
This is not a limitation for scratchbox[1], using cpu transparency via
sbrsh or qemu tests *can* be executed. Ofcourse, for i386-uclibc this is
even less of a problem, as binaries can be executed without problem on
the cpu as long as ld.so and other libs are expected places. Which
brings us to the other problem scratchbox solves (shameless plug!!)
Libary locations and library search paths. dpkg-cross and every other
crosscompiling solution moves libraries to unexpected locations. You no
longer can "just apt-get" the target arch libs you need. This is
managable as long as you stick with autoconf -based software, but you'll
go nuts with the more esoteric build systems, like the one of apache.
Even with autoconfed apps, things like gtk and pango are not easy to
crosscompile.
Even then, modifying each and every debian package is a daunting
process. It's easier to provide a crosscompiling solution that makes
the applications not notice that they have been crosscompiled. This i
what Nokia is using too ;)
Inside scratchbox, the normal /lib, /usr/lib, and so on directories are
filled with target arch libs and binaries, and apt-get install installs
target arch pacakges. /scratchbox is then filled with host arch tools
and crosscompilers.
[1] http://www.scratchbox.org/
Reply to: