Re: cross-compiling Debian packages
On Mon, Mar 13, 2006 at 04:36:33PM +0200, Riku Voipio wrote:
> 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
> firstname.lastname@example.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, 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
In general, you can not apt-get packages compiled for different
archs or OS's. Why should you be able to just apt-get packages
compiled for different Libcs?
> 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
The fact that they do not cross-compile cleanly is a sign that they
are written using wrong assumptions, such as CC=gcc or
-lc=libc.so.6. Should we not try to fix this at the source, i.e. in
the packages themselves? This would help BTW not only in
cross-compiling but also when the toolchains is upgraded.
> Even then, modifying each and every debian package is a daunting
> process. It's easier to provide a crosscompiling solution that makes
This can be gradual process of first getting a warning from
> the applications not notice that they have been crosscompiled. This i
> what Nokia is using too ;)
Again, this feels wrong. You don't remove complexity of cross-building
by adding more complexity on top.
> 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.
>  http://www.scratchbox.org/
Will look into that, thanks!
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com