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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
