Neil Williams wrote:
Yes, in the sense that they take an abstract and translate it into something that is runnable. In many cases, this involves at least macro substitution, but in some cases it's simply a rename of the original file in order to duck around read-only source repositories, shared source/multiple object build processes, etc.On Mon, 05 Mar 2007 15:53:09 -0800 "K. Richard Pixley" <rich.pixley@palmsource.com> wrote: I usually think of "building" as turning some sort of source into some sort of object. Dpkg-cross doesn't do this. Instead of being a translation from high level to low level, it appears to be more of a lateral translation - from one packaging format to a slightly different form of the same packaging format. Use of the word "build" to describe this translation seems confusing to me because to me "build" strongly suggests a translation from a higher level of abstraction to a lower level of abstraction.Building a package like a Gtk theme or icon set is simply collecting existing binaries into a standard format binary. Debian Policy mandates a few extras but the basic package does not have to be a lot more than a pair of tar.gz files collated using ar. I would like to suggest that the word "translation" be substituted in the dpkg-cross doc in place of "build". I think this would make dpkg-cross's purpose in life more clear. FWIW, I've had several co-workers come to me to tell me about dpkg-cross thinking that it had something to do with actual cross compiling. So this confusion is apparently fairly wide spread. Come to think of it, "cross" here is also a misnomer. Yes. Cross compilers are the easy part. I'm struggling with the packaging issues now.Yes. dpkg-cross is only part of the solution. The main component of cross building is a cross toolchain - a recompiled version of gcc that outputs 'alien' ELF binaries. When you build a package, the output messages may mention 'cc' or similar. When cross building, the output messages mention 'arm-linux-gcc' or similar. i.e. you compile the package using a replacement compiler. *nod* I'm intimately familiar with that process for the gnu tools. I designed much of it.Building that compiler is done by specifying the target architecture to the gcc source code. Ah. I see. Thanks. That was a clue I needed. It hadn't occurred to me that it would be bolted to a specific compiler or toolchain name. That's... well, it's antithetical to the gnu approach.This is achieved using 'dpkg-buildpackage -a arm' which causes dpkg to look for a version of gcc compiled for arm compatible output. With this clue, I can now cross build arm packages, (though not armel). Maybe it's just me being dense, but I'm still not getting what emdebian-tools do or how to use them. Emsetup -s just gives me errors, (on sarge, etch, and sid). "Emsetup -s -a armel" produces similar complaints along with perl complaints. And "emchain -a armel" produces a page or two of perl errors followed by: emchain: Build failed. See the dpkg build log for more info. If I'm understanding, though, y'all are building tool chains with specific gnu type prefixes. dpkg-buildpackage, with the help of dpkg-cross modified debhelpers calls these carefully named toolchains. If I substitute in an eabi compilers, carefully naming it the same way as the old arm oabi compiler, I can compile using dpkg-buildpackage, but I can't get through the rest of the debhelpers. Of the handful of packages I've tried so far, the each die in different places. Rather than wade into trying to address these, I figured it was time to sync up and make sure I was working the way the rest of you were before going much further. --rich |