Hi!
As you may know, I'm working on
multiarch cross-toolchains as part of the
Google summer of Code (see
my previous post for details), and although there is still a lot to do, the project is doing fairly well, and a cross-gcc is already installable and working.
I'll proceed with detailed instructions on how to install the cross-compiler, along with some explanations on multiarch itself, and how to build cross-toolchains from source.
Prerequisites
First, you need specific versions apt (>= 0.9.6) and dpkg (>= 1.16.5).
This is because the cross-toolchains packages I'm working on depend on specific cross-arch dependencies, such as libc6:armhf.
Support for such dependencies has been added in the aforementioned versions of apt and dpkg.
This means you should be running unstable, or at least use dpkg from unstable.
Adding a foreign architecture
Adding a foreign architecture is straightforward, but I've seen users do overcomplicated, or just plain wrong things.
So, let's do this step by step (well, there are only two of them), with some explanations.
- Tell dpkg to handle an additional architecture by typing
dpkg --add-architecture armhf.
There isn't much to say. It will only add an architecture to the list of architectures dpkg would accept to handle.
- Update APT's database. You need to run
apt-get update after adding or removing an architecture to get package lists for all wanted architectures and rebuild APT's database, including the implicit cross-arch dependencies/conflicts brought by multiarch.
And that's it for the common case. Now, a word on architecture restrictions: a common misconception about multiarch seems to be that you have to tell APT which architectures you want from the mirrors by modifying your sources.list file(s). This is not true, as, by default, APT gets the list of accepted architectures from dpkg, and gets the correct package lists from the mirrors configured in the sources.list. You only need to use arch restrictions ( deb [arch=arch1,arch2,...] ... ) when you want to get packages from a mirror
only for a subset of your accepted architectures. This is
very unlikely, and in the general you
do not need to modify your sources.list, at all.
Getting the cross-compilers from my
repository
I provide compiled versions of gcc-4.7-arm-linux-gnueabihf for i386 and amd64 in my
repository.
If you have followed the previous paragraphs, nothing should be easier than adding a deb http://emdebian.org/~thibg/repo/ sid main line to your sources.list and doing the following:
# apt-get update
[...]
# apt-get --no-install-recommends install gcc-4.7-arm-linux-gnueabihf
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
binutils-arm-linux-gnueabihf cpp-4.7-arm-linux-gnueabihf gcc-4.7-arm-linux-gnueabihf-base gcc-4.7-base:armhf libc6:armhf libgcc1:armhf
libgmp10 libgomp1:armhf libmpc2 libmpfr4
Suggested packages:
binutils-doc gcc-4.7-locales libmudflap0-4.7-dev:armhf gcc-4.7-doc libgcc1-dbg:armhf libgomp1-dbg:armhf libitm1-dbg:armhf
libquadmath-dbg:armhf libmudflap0-dbg:armhf binutils-gold glibc-doc:armhf locales:armhf
Recommended packages:
libc6-dev:armhf
The following NEW packages will be installed:
binutils-arm-linux-gnueabihf cpp-4.7-arm-linux-gnueabihf gcc-4.7-arm-linux-gnueabihf gcc-4.7-arm-linux-gnueabihf-base gcc-4.7-base:armhf
libc6:armhf libgcc1:armhf libgmp10 libgomp1:armhf libmpc2 libmpfr4
0 upgraded, 11 newly installed, 0 to remove and 0 not upgraded.
Need to get 23.5 MB of archives.
After this operation, 57.2 MB of additional disk space will be used.
Do you want to continue [Y/n]?
I've disabled the recommends since, libc6-dev:armhf would recommend gcc:armhf itself, which is not co-installable with your native gcc if you have it installed.
Building the cross-toolchain yourselves
If you don't trust the repository above, or simply want to rebuild the toolchain yourself, it is rather simple:
get my
gcc-4.7 patches and:
$ apt-get source binutils
$ cd binutils-*/
$ TARGET=arm-linux-gnueabihf dpkg-buildpackage -uc -us -b
$ cd ../
# dpkg -i binutils*arm-linux-gnueabihf*.deb
$ apt-get source gcc-4.7
$ cd gcc-4.7/
$ for patch in path/to/the/patches/*.patch; do patch -p1 < $patch ; done
$ GCC_TARGET=armhf debian/rules control
$ GCC_TARGET=armhf dpkg-buildpackage -uc -us -b
Using the cross-compiler
It's easy, but there is a trick, and
dpkg-buildpackage -aarmhf won't work out of the box yet, as gcc-4.7-arm-linux-gnueabihf provides the arm-linux-gnueabihf-gcc-4.7 executable, but no arm-linux-gnueabihf-gcc symlink.
So, for the moment:
$ cat > test.c << __EOF__
#include <stdio.h>
int main(void)
printf("Hello world\\n");
return 0;
__EOF__
$ arm-linux-gnueabihf-gcc-4.7 test.c
$ qemu-arm ./a.out
Hello world
Conclusion
The toolchain is not complete yet (there is some more work to do on binutils and
libstdc++, and equivalents to the gcc , cpp , and build-essential packages to provide), but it should still be useful to cross-compile C programs.
Multi-arch cross-toolchains for wheezy can definitely be hosted at emdebian, and I hope to clean up the build process so that it could get included in the archive for wheezy+1.
Second day in managua, second day running.
Today, after breakfast, so at about 7h45, I went out running with
Gaudenz Steinlin. The goal was to go to laguna
de Tiscapa, a lagoon of volcanic origin, in the middle of the city
of Managua.
The laguna is not really far away from the place we're staying at
(about 2.5km). However, as usual here, the only way to get there is
along the streets. Noisy streets. Often smelly streets. But that's the
only way.
For instance, it
took Gaudenz several minutes before he could manage
to cross the "Pista Beljamin Zelodon", a quite busy highway.
The lagoon per se is really nice, particularly the
view from the
Sandino monument where you can see the Peninsula
de Chiltepe.
However, apart from that, it was sometimes a quite boring run because
of the traffic, noise, etc. But I enjoyed again having a good run with
Gaudenz. We'll do this again, but in another place..:-)
GPS trace for that run is here.
For my GSoC project this year I need to be able to enumerate all elementary
circuits of a directed graph. My code is written in Ocaml but neither the
Update on computational chemistry packages in Debian
Pretty much on schedule, 
on how to deliver that, together.
DebConf12
A lot of us will attend DebConf12. Enjoy it! ... and take the
chance to both have fun and make great plans for Debian's future.
But remember that "if it didn't happen on a mailing list, it didn't
happen". Not all of us will be lucky enough to attend DebConf (in
person or remotely). Make sure that those who don't can take part
in your team decisions and get informed of what is going to happen
here.
Politics
A new release of the RcppBDT package appeared on
I spent a bunch of the past week trying to figure out why my 
I'm a heavy user of Debian's 
Ever.
(this service message brought to you by the society for
reimplementing what used to be a bad idea in another
language)
This is my monthly summary of my Debian related activities. If you re among the people who 
