Differences between revisions 1 and 2
Revision 1 as of 2006-04-12 10:21:41
Size: 5421
Editor: MartinGuy
Comment: State the problem
Revision 2 as of 2006-04-12 10:25:10
Size: 5427
Editor: MartinGuy
Comment: Drop repeated word
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
while cross-compilers for individual mainline targets are produced adhoc by bright individuals for a random selection of architectures, with a random selection of support libraries, invariably running only on i386 machines: while cross-compilers for individual mainline targets are produced as-and-when by bright individuals for a random selection of architectures, with a random selection of support libraries, invariably running only on i386 machines:

Debian-packaging the output of crosstool

Abstract

Support for cross-compiler packages in Debian is patchy and adhoc at present. The main Debian archive includes

  • gcc-avr for Atmel AVR targets
  • gcc-h8300-hms for Hitachi H8/300[HS] processors
  • gcc-m68hc1x for Motorola 68HC11/12 processors

while cross-compilers for individual mainline targets are produced as-and-when by bright individuals for a random selection of architectures, with a random selection of support libraries, invariably running only on i386 machines:

deb http://www.emdebian.org/emdebian-tools/stable ./
deb http://zigzag.lvk.cs.msu.su/~nikita/debian/ sarge/
deb http://zigzag.lvk.cs.msu.su/~nikita/debian/ sid/

[http://kegel.com/crosstool Crosstool] is able to produce working cross-compilers for c and c++ with a standard set of support libraries (libgcc and glibc) for all the debian-supported architectures that run on all the supported debian architectures. If we could Debian-package the output from crosstool this would be a big step forwards for Debian cross compiler land.

At present (crosstool-0.42), crosstool is not "productized" but is a hackers' playpen. You configure and run it in its own source directory and it installs cross-compilers under /opt/crosstool. There is a script "makerpms.sh" which should build RPM files of the results; if we could write a "makedebs.sh" script that produced .deb files conforming to Debian conventions, we would be laughing. That is what this page is all about.

Is it possible?

Crosstool's demo scripts install into its own idiosyncratic directory structure, for example /opt/crosstool/gcc-4.0.1-glibc-2.3.6/arm-none-linux-gnu/ containing directories arm-none-linux-gnu bin distributed include info lib libexec man share tmp and refuse to install into / or /usr (because it would delete their contents before starting!).

There is already a SYSROOT=1 hook that distributes things between .../lib, .../usr/lib and .../usr/include within its build directory, and it has a script that claims to "fix embedded pathnames". However, installing all the components into the correct places in the Linux filetree may require some study.

Is it legal?

Debian standard are stringent. At present crosstool itself is not even installable, let alone packagable, so cannot be specified as a build dependency. Presumable, the binary .debs produced by crosstool would not have corresponding source packages, since crosstool itself is not Debianised (and is not likely to be Debianisable without a major rewrite).

If not, it might still be legal to make an independent repository containing the binary .deb's, with apologies and instructions for building them.

Has it already been done?

Do toolchain-source, dpkg-cross, scratchbox (and others?) already do what we are trying to do?

toolchain-source

toolchain-source is a Debian package that "contains everything that is needed to download and compile all packages that are required for a cross compiler (that is to say, gcc, binutils and libc...)"

Actually it contains its own copy of the source code for a specific version of GCC (3.4.5). It is supposed to be able to produce cross-compilers, but is now deprecated, its maintainer wants to abandon it and there is no framework for upgrading to newer version of the toolchain components.

dpkg-cross

dpkg-cross "is a tool for installing libraries and headers for cross compiling in a way similar to dpkg. Furthermore, the functionality of dpkg-buildpackage and dpkg-shlibdeps is enhanced to support cross compiling."

It seems to do this by downloading native C library packages and headers for alien architectures and installing them as cross-development libraries on the native platform.

It looks like a friend, but does not manage the cross-compilers themselves.

scratchbox

"Scratchbox is a cross-compilation toolkit designed to make embedded Linux application development easier. It also provides a full set of tools to integrate and cross-compile an entire Linux distribution."

What is more, it uses QEMU to emulate the target system on the host so that "configure" scripts can run compile test programs (for the target architecture) and run them, and never twig that they are not running on the target arch.

It is Debian-friendly (see package scratchbox-devkit and sb-) and even says "You can create tarballs and Debian packages inside Scratchbox" and they provide some Debian packages at

deb http://scratchbox.org/debian ./

including a scratchbox-devkit-debian

Sound promising! However, it only provides actual crosscompilers for i386->arm work. It has a documentation page on [http://www.scratchbox.org/documentation/user/scratchbox-1.0/html/toolchain.html making your own toolchains]. The web site then glibly says

  • Scratchbox.org offers prebuilt toolchains for x86 and ARM targets. Only these targets are currently supported because too much work to support all different configurations. With the Scratchbox toolchain sources you can build your own custom toolchains.

Conclusion: Despite its promises, scratchbox seems to be a tool for building software using crosscompilers, but any actual cross-compilers for it are built individually by gurus.