On Thu, 08 Mar 2007 13:51:28 -0800 "K. Richard Pixley" <rich.pixley@palmsource.com> wrote: > > Building doesn't have to mean compiling - packages based on bash > > scripts are still described as built. > 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. 'translation' has a very specific meaning in packaging. IMHO, 'building' is fine. > > 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 usually think of "building" as turning some sort of source into some > sort of object. No, that is compilation. Turning source code into an object requires a compiler. You do not need a compiler to build a package. You need a compiler for some packages, definitely, but not for all. You can build packages without debhelper but only with a lot of painful work reimplementing debhelper operations in some other form. > Dpkg-cross doesn't do this. Correct - it is not intended to do so. > 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. The packaging format is precisely identical - changes are restricted to the package name and package contents. This is no different to tweaking a text file in a normal Debian package - the package is still built. > 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. dpkg-buildpackage does not use that meaning - buildpackage is analogous to tar -cf. It takes a collection of files, parses the meta data, relocates and renames some files, ignores others, adds a few of it's own and lumps the whole lot together as a binary file of a very specific format. Building does not have to involve compilation, it just happens to occur within the build process in many cases. > 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. I think it would confuse everyone dealing with i18n and l10n issues. > 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. dpkg-cross has a LOT to do with cross-compiling! It's used for nothing else. It doesn't have to be a compiler to be involved in cross-compilation - cross-compilers need a lot of support tools and packages. dpkg-cross provides the library support when cross-compiling anything outside the basic busybox / bootstrap environment. To cross-compile libxml2 (without python), you first have to dpkg-cross built zlib. To make a usable libxml2 binary, you also need to cross-compile zlib but because you can't RUN the cross-compiled zlib on the machine doing the cross-compile for libxml2, you need to the use dpkg-cross to make the cross-built zlib available. In my situation, my cross-compiling machine is amd64. My target arch is arm. I use apt-cross to obtain the natively built Debian arm package but I could also cross-compile zlib and the use dpkg-cross. The effect is the same, a version of zlib for arm that is installable on my amd64 machine. The dpkg-cross version (suffixed -cross) is only usable by arm cross-builds. Normal builds use the original amd64 zlib that is completely unchanged. I end up with two versions of zlib installed, the native amd64 and the arm-cross version built and installed with apt-cross (which calls dpkg-cross to do the work). > Come to think of it, "cross" here is also a misnomer. Not at all, cross relates directly to cross-building. 'cross' has a specific meaning: taking built (not necessarily compiled) packages from one architecture and making them suitable for a foreign architecture. That's the cross. Normal building results in an amd64 package on an amd64 machine - cross building results in (e.g.) an arm package on an amd64 machine. http://linux.codehelp.co.uk/emdebian/man/re01.html man emdebian-tools > > This is achieved using 'dpkg-buildpackage -a arm' which causes dpkg to > > look for a version of gcc compiled for arm compatible output. > > > 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. ? In what way ? > > With this clue, I can now cross build arm packages, (though not armel). You need an armel toolchain for that. :-) > > http://www.linux.codehelp.co.uk/#emdebian-tools > > http://www.linux.codehelp.co.uk/emdebian/man/ > 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). That doesn't help me to help you (and emdebian-tools is currently only for sid, not etch or sarge). What errors? Have you installed the emdebian-tools package or have you just checked out the script from SVN (i.e. are you missing dependencies specified in the package?) BTW. 'emsetup -s' , not 'Emsetup -s' Perl errors mentioning @INC are dependency issues - see the debian/control file for information on the dependencies required by emdebian-tools. Installing the package direct from Debian unstable with apt will bring in these dependencies for you. emdebian-tools does not support etch or sarge because some dependencies are not present in etch and most of the sarge dependencies are far too old. > "Emsetup -s > -a armel" produces similar complaints along with perl complaints. Sounds like dependency issues. > And > "emchain -a armel" produces a page or two of perl errors followed by: That could be an issue with armel in the underlying dpkg-cross code. Have you tried 'emchain -a arm' ? > If I'm understanding, though, y'all are building tool chains with > specific gnu type prefixes. That's the Debian way (AFAICT it's also the GCC way and by inference the GNU way). > 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. Emdebian is all about Debian and therefore has deep and intricate dependencies on Debian package building code, including debhelper. Trying to force emdebian-tools to work with non-gcc compilers that are not supported within Debian is only going to give you problems. If you want a build method that is not tainted with Debian build methods, I would suggest OpenEmbedded. > Of the handful of > packages I've tried so far, the each die in different places. Nothing unusual in that. :-( > 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. Sounds about right. Most packages do not cross-compile successfully first time. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgprdnaMqYpbe.pgp
Description: PGP signature