[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

cross-compiler mini-HOWTO 0.0.1



Finally I have my mental notes into a somewhat coherant form. I welcome
any suggestions, pointers, etc. This is my first time writing an HOWTO.

I had planned to write a little script to perform the steps described
here, but I ran into a little policy-esque technical snag that I needed
some expert advice on. However, it's been about a week with not even a
reply to the questions I asked on debian-devel. Perhaps I could find the
advice I seek here?

HOWTO is attached.
[document 0.0.1]
[copyright 2000, Beiad Ian Q. Dalton. Permission to distribute and
maintain this document in the same manner as the HOWTO collections is
hereby given.]


This HOWTO describes a "quick and dirty" way to produce a minimal
cross-compiling system. A cross-compiler is used to compile software on
a fast machine of one archetecture for a slower machine of a different
archetecture. A good example of this is compiling for a 68k Mac or a
Sparc IPX or SS10 on a recent Pentium II system.

This HOWTO currently assumes that you will be performing all the steps
as root.

You need:

    A fairly fast computer with Woody installed on it. Potato should
    work as well, but I don't have a system I can test for it.

    Access to Woody's source package archive.

It's probably a good idea to do all this under /usr/local/tmp or
/var/tmp, or a scratch partition, if you don't already have your own
set-up to compile local packages.


Download and unpack the following source archives: (apt-get source is
best if you have an Internet connection)

	binutils 2.10
	gcc-m68k-linux 2.8.1
	
If you're going to build for a Sparc target, you may also want to get
the sparc-utils package for the elftoaout converter and the tftpboot
stuff.

Now download 'lsdo', 'libc6', and 'libc6-dev' binary debs for your
target archetecture and distribution.

Now, install dpkg-cross, if you don't have it already. You will must to
edit /etc/dpkg/cross-compile and change 'crossbase' to be '/usr' instead
of '/usr/local'. gcc 2.8.1 will not build successfully if you do not do
this.

Use dpkg-cross to install the ldso, libc6, and libc6-dev packages that
you download, one package per invocation.

Now, cd into the binutils source directory and type
'debian/rules TARGETS=<dest arch> binary'

When the build has completed successfully, you should have 'binutils',
'binutils-dev', 'binutils-doc', 'binutils-multiarch', and 
'binutils-<dest arch>'. At a minimum you should install the 'binutils',
'binutils-dev', 'binutils-multiarch' and 'binutils-<dest arch>'
packages.

Now, you should be ready to build gcc.

IFF your target arch is not m68k:
    cp -a gcc-m68k-linux-2.8.1 gcc-<target arch>-linux-2.8.1
    With a text editor (sed should work fine here) change all instances
    of 'm68k' to '<target arch>' in all files in the 
    gcc-<target arch>-linux-2.8.1/debian/ directory.

Now, cd into gcc-<target arch>-linux-2.8.1 and run 
'debian/rules binary'.

Assuming this compile succeeds, install the gcc-<target arch>-linux deb.


Known problems:

You need gcc 2.91 in order to compile the 2.4.0 test kernels. If the gcc
source package could be extended in the same way that binutils was, we
could obsolesce the gcc 2.8.1 package and Be Happy.

Currently, if you don't have 'crossbase = /usr' it will Fail To
Build. This is because the Makefile in gcc 2.8.1 isn't smart enough to
consider that the header files and the binutils might not be in the same
superdir, and I'm just not up to trying to Make It Work. Besides, making
2.91 work would be a better use of effort.

; It also doesn't appear possible to make a script that could be packaged
; and added to Debian, currently. The sticking point is the issue with
; dpkg-cross. In order to work, the script basically has to make the admin
; change the value of crossbase, or be allowed to override it on the
; dpkg-cross commandline. I asked about this on debian-policy, also
; asked the binutils maintainer in private email, but have heard
; nothing.
; Personally, I think overriding the admin's decision isn't the best
; idea, but it is the best thing to make the script do what it's
; supposed to, given the current state of the packages it needs.


Reply to: