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.
A few days ago I had
blogged about getting NumPy data in R
by using a simple converter script. That works fine, but it is a little
annoying to have to write an entire file only to read from it again. So I
kept looking around for a better solution---and soon found
the cnpy library by Carl Rogers
which provides simple C++ functions to read and write NumPy files.
Bringing such a C++ library to R is done very easily via Rcpp modules.
The resulting package contains a single R file with a single line:
Correct me if I m wrong (and I really want to be wrong).
The Grand Plan today was reaching the end of the road I already
explored on Tuesday. Named "Camino Las
Viudas", it's climbing in the southern hills up to a place named
"Intermzeeo del Bosque", apparently a very fancy (and expensive)
restaurant.
The road climbs in the apparently "rich" neighbourhood of Managua,
with very fancy villas as guarded by private security, as well as
private condominiums, guarded as well.
What's funny to see is that, at the bottom of the road, when it
crosses a large avenue (Pista Suburbana Espana), you can find several
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
Pretty much on schedule, 
Should I recommend that 
I spent a bunch of the past week trying to figure out why my 
I'm a heavy user of Debian's 
Already chilled by 
liblog4ada 1.2-1 surely had, as it was accepted after 30 seconds! gsoap 2.7.17-1 was not so lucky, it took 103 days, 8 hours, 20 minutes and 43 seconds to clear NEW, but then made its way to the archive. Better late than never 
Whilst nobody was looking, Mono became the most important framework in the world of games.
And I mean that with only a smidge more than my usual levels of hyperbole. It really is fantastically important, as far as game development goes.
I blogged a long time ago about its use inside EA s multi-million-selling The Sims 3. And the massive performance gains in Second Life when they switched from their in-house scripting language to Mono are well documented. But I m not talking about those, I m talking about the now, the recent stuff.
First up is Unity 3D. Not to be confused with the Ubuntu user interface, Unity 3D is a proprietary game development tool which began life for Mac, and has now managed to become 
