Differences between revisions 11 and 12
Revision 11 as of 2006-04-21 17:16:20
Size: 8528
Editor: MartinGuy
Comment: H3 -> H2
Revision 12 as of 2006-04-21 18:22:19
Size: 8640
Editor: MartinGuy
Comment: Mention buildsrpms.sh
Deletions are marked like this. Additions are marked like this.
Line 125: Line 125:
Making the corresponding set of interdependent Debian packages, with source packages that you can "build" seems a monstrous task. Making the corresponding set of interdependent Debian packages, with source packages that you can "build" seems a monstrous task. That said, the existing <TT>buildsrpms.sh</TT> in crosstool claims to make source RPMs that you can "rpmbuild".

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 a huge number of host/target machine combinations, including 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 and tmp and refuse to install into / or /usr (because it would delete their contents before starting!).

There is already a USE_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 .debs, with apologies and instructions for building them.

Has it already been done?

Do toolchain-source, dpkg-cross, binutils-multiarch, scratchbox,the emdebian project (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.

binutils-multiarch

Version of binutils programs "to manipulate binary and object files that may have been created on other architectures. ... a cross-assembling version of gas is not included in this package, just the binary utilities."

No good. We need to provide the whole set of cross-binutils utilities.

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.

emdebian

The embedded Debian project [http://www.emdebian.org/crosstools.html documents a simple procedure] for building binary Debian packages for cross-compilers from existing Debian source packages (gcc, glibc, binutils). It relies on the versions of the sources you need to use already being included in Debian.

Differences

Here is a list of some of the things that need changing to Debianise crosstool's output

Binary names

The demo scripts create arm-unknown-linux-gnueabi-gcc and friends. These need to be installed in Debian as arm-linux-gnueabi-gcc etc (maybe just change the arch in the .dat file?). Mind you, this would conflict with existing cross-compiler names. Would arm-crosstool-linux-gnueabi-gcc be better (using the "vendor" field of the GCC target name)?

Installation directories and embedded pathnames

Needs to install into a separate filesystem tree to then be packaged (using crosstool option USE_SYSROOT?). The existing Emdebian packages

  • gcc-3.4-arm-linux
  • g++-3.4-arm-linux

pull in

  • binutils-arm-linux
  • cpp-3.4-arm-linux
  • gcc-3.4-base
  • libc6-dev-arm-cross
  • libgcc1-arm-cross
  • libstdc++6-0-arm-cross
  • libstdc++6-0-dev-arm-cross

and install to

  • /usr/bin/arm-linux-{ar,as,gcc,g++,etc...}
  • /usr/bin/arm-linux-{cpp,gcc,g++}-3.4
  • /usr/lib/gnu/arm-linux/3.4.4/include/*
  • /usr/lib/gnu/arm-linux/3.4.4/cc1,cc1plus,libgcc.a, etc...}
  • /usr/arm-linux-gnu/{bin/{ar,gcc,g++,...}
  • /usr/arm-linux-gnu/include/*.h
  • /usr/arm-linux-gnu/lib/*.{a,so}

and strangely also to:

  • /usr/arm-linux/include/c++/3.4/*/*.h
  • /usr/arm-linux/lib/libstdc++6*.so

though this may be an error.

Crosstool installs into $RESULT_TOP/gcc-4.1.0-glibc-2.4 with directories

  • bin/arm-none-linux-gnueabi-{ar,as,gcc...}
  • lib/libiberty.a
  • lib/gcc/arm-none-linux-gnueabi/4.1.0/{crtbegin.o,libgcc.a,...}
  • include, info, man
  • libexec/gcc/arm-unknown-linux-gnueabi/4.1.0/cc1

and is also known to favour /opt/crosstool as a system installation directory.

Making the corresponding set of interdependent Debian packages, with source packages that you can "build" seems a monstrous task. That said, the existing <TT>buildsrpms.sh</TT> in crosstool claims to make source RPMs that you can "rpmbuild".

Is turning the crosstool output tree into a single all-in binary package for each target under /opt/crosstool Debian-acceptable?

Naming the packages

For instance, crosstool-0.42-arm-linux-gcc-4.0.2-1_i386.deb for the crosscompiler targetting ARM that runs on i386 class machines?

With a little study, the g++ components can be split off into a separate package dependent on the gcc package, and maybe arch-independent bits into *_all files.