Episode: 1706
Title: HPR1706: Cross-compilers part 1
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1706/hpr1706.mp3
Transcribed: 2025-10-18 08:04:02

---

This is HPR episode 1,706 entitled Cross Compilers Part 1.
It is hosted by Mike Ray and is about 27 minutes long.
The summary is what is cross-compiling and why I might want need to do it.
This episode of HPR is brought to you by an honesthost.com.
Get 15% discount on all shared hosting with the offer code HPR15.
That's HPR15.
Better web hosting that's honest and fair at An Honesthost.com.
Hello, welcome to Hacker Public Radio.
My name is Mike Ray and you'll notice that I've dropped that corny morse code at the start
of the show.
So on was what I had to talk about today.
Now this was supposed to be a show entitled Raspberry Pi version 2, First Impressions.
I reserved the slot for 1,706 a couple of weeks ago when the Raspberry Pi version 2 was
announced and I got a hold of a couple quite quickly.
I woke up on a Sunday morning without any clue that this was going to happen.
I had no idea that the Raspberry Pi 2 was out, was going to be released but I got up on
Sunday morning, looked at my email, saw a few emails from the serial inexcuser group about
the Raspberry Pi 2 and immediately went to mod my Pi in order a couple, managed to get
in before they sold out.
I think there's quite a lot of difficulty with actually getting any of these at the moment.
The two Pi's I ordered arrived Tuesday, Wednesday, a couple of weeks ago, three or three days
after I ordered them so I immediately started tinkering.
At that time I reserved the 1,706 slot because I thought, you know, within a couple of weeks
I'll have some things to talk about but like everything else, when I start doing one
thing I get distracted and I go off at a tangent and end up doing something else and that's
true for this.
How this occurred was that the Raspberry Pi 2 is a different ARM processor.
The original Raspberry Pi is an ARM Cortex A6 architecture and the Raspberry Pi 2 is an
ARM Cortex A7 so in order to cross compile a kernel I needed another cross-compiler.
Now so we come on to the subject of cross-compilers.
The title of this show is now cross-compilers Part 1 and I'm going to describe to you what
cross-compilers actually are, why you might be interested in using them or why in fact
you might actually need to use them, it might be an imperative there.
So what is a cross-compiler?
Now as a Linux user we're all familiar with the usual process of using the GNU tools,
PCC, G++, LD, etc. to compile and link C or C++, possibly Fortran on Linux to run on Linux.
Typically if you're sitting in front of for example a 64-bit machine you're running
x8664 Linux, you're right in code or downloading code, you're compiling it on the x8664 machine
to run on the x8664 machine, that's great, that's just plain old vanilla building and
everybody is familiar with the very familiar sequence.slash configure, make sudo make install
and everybody will be familiar with gcc-o programname, programname.c which will produce
compile and link programname from programname.c source code.
Now what do you do if you're writing code for a platform where there is no C compiler,
possibly even no display of sorts, no console to log into, no keyboard, no text editor
for you to hack away at your code, supposing you're writing code for an embedded system.
And of course Linux is showing up on lots of domestic devices now, lots of handheld electronic
gadgetry. Now suppose you work for a company that makes kitchen appliances and your latest
product is going to be a microwave oven which has an embedded microcontroller in it,
which lots of machines need it because building something complex with discrete components
is far more expensive, far more complicated than using these wonderful little programmable
chips nowadays. Now of course a microwave oven doesn't have a monitor, keyboard, editor
all the stuff I was talking about so this is where you're going to need to cross compile
and what cross compiling is writing, compiling and linking code to run on an architecture
from a different architecture. So for example, if your microwave oven has got an ARM chip in it,
you may be using a cross compiler to write code on x86, 64 Linux to run on the ARM processor
on the microwave oven. So that's where the term cross compiler comes from, you're actually
compiling on one architecture to run on another architecture. Now the tools that we need for
doing that are typically known as a tool chain. It's called a tool chain because it contains
quite a bit more apart from just the C compiler, there's the compiler, C libraries, other libraries
that are needed by the tool chain, the linker and other familiar new tools like AR, RunLib etc.
So this is a cross compiler tool chain. Building a tool chain involves actually compiling a compiler,
which is quite a tricky task and it involves compiling bin utils, stuff that will
the C libraries etc. So it's quite a tricky business. Luckily there is a fantastic tool which I
found called cross tool ng, which I'll go into in a minute. Now this is slightly out of correct
order, but to talk about why I got into this cross compiling business and why I was distracted
from actually evaluating the Raspberry Pi 2 to get into the business of cross compiling,
you can actually download a cross compiler tool chain from the Raspberry Pi foundation, from Git Hub,
but unfortunately it only runs on a 32 bit environment. So if like me you have a 64 bit PC running 64
bit Debian, the Raspberry Pi foundation tool chain will not function. So then I got into trying to
run a virtual machine using virtual box and something called vagrant, which is sort of a virtual machine
management tool if you like. And then of course the Raspberry Pi 2 came along, so I needed an ARM
Cortex A7 cross compiler and the only ones I could find online for download were 64 bit.
So I had, so I'd created a 32 bit virtual machine, a Ubuntu precise 32 bit using vagrant and
virtual box and then I tried to create a 64 bit virtual machine because when I tried to use the
cross compiler that I downloaded on my 64 bit Debian machine, the C libraries I have were not
up to the version required and I wasn't prepared to miss about updating C libraries on Debian,
Debian Weezy just to get the cross compiler to work. So that is when I looked further into
cross tool ng, which I'd sort of already used, but I now had a greater degree of urgency
to actually get to use it and to build a pair of tool chains, one for ARM Cortex A6 and one for
ARM Cortex A7 so that I could compile for both the older Raspberry Pi and the version 2.
Now I think also ARM Cortex A7 I think will also compile for banana Pi, but that's another story.
So then I started looking around for information about configuring the build for the tool
change. Now cross tool ng is quite easy to configure. Now the show notes by the way are very
comprehensive or the HTML version. The show notes are very comprehensive. Tell you all about how to
install cross tool ng and how to configure it. It's very clever. If you ever done a kernel
compile you'll be familiar with the .config file which you need in order to set up a compile
and to pick all of the right settings modules and kernel modules etc before you actually build
a kernel. And there is a tool called menu config which you can run which gives you an
in-curse screen to make adjustments to this config file. Now Clato did an excellent show about
compiling a kernel. So I'm not going to dig too deeply into that but suffice to say
it will be familiar to you if you've ever set up for a kernel compile the
cross tool ng's configuration tool will be very familiar. Accessibility is not fantastical in
curses and as I can't see I struggle a little bit with in curses applications so I then went
looking for online to see if anybody had already done what I wanted to do and fantastically I discovered
on the Arch Linux ARM site that there is a set of .config files for cross tool ng for there's
actually three of them. ARM Cortex A5, ARM Cortex A6 and ARM Cortex A7. So I downloaded the A6 and A7
configs and used them to drive a build of a pair of tool chains. I need to talk now about something
which really screwed up my head when I first started looking at cross compiling because
there was a piece of information I was missing and it was one of these things where
you constantly look online and Google for the answers to the questions and you never find it
and you start to think all of these blogs and all of these tutorials that I've read and I can't
find the answer. Is it something which is so obvious that all of the authors of these pages
simply don't have to mention it and if so why is it taking me so long to find the answer?
Is it something, you know, am I stupid? Am I doing something wrong? And the question was
how do I tell the cross compiler when I'm building code on my Linux machine to run on my Raspberry Pi
where to look for the libraries which it will need to include in the software. For example,
if I'm running it, if I'm compiling something like I've written and it needs, for example,
Pthreads, you know, Pthreads is a very common library. I can't link in the Pthreads library that
I'll find under user lib x8664 GNU because that's x8664 code so that won't work. So where do I put
the library, the ARM version of the library so that it will be found by my cross compiler and the
answer is something called Sysroot, S-Y-S-R-W-T. Every GNU tool, certainly GCC and LD,
has internally set a Sysroot and what this is is a value which will be a string path
which will be pre-pended to any search paths for libraries. Now if you do on your Linux machine
just type GCC, space, dash, print, dash, Sysroot, you'll probably get back either as just a slash
or an empty string because there is no, you know, Sysroot is root on the native platform.
But if you have a cross compiler tool chain built then the Sysroot will be somewhere deep within
where you've installed the cross compiler tool chain and this is something which
actually caused me a problem when I first built a tool chain because I built it in a directory
under my home directory and then I moved it because I like these things tool chains,
kernel source etc to be under slash OPT. Now when you generate a tool chain the Sysroot gets
hard coded into GCC and LD and other tools and if you move the tool chain it will then be wrong.
There is a switch dash, dash, Sysroot equals blah, blah, blah which will allow you to
set the Sysroot but you don't want to have to do that each time. You certainly don't want to have
to do that if you're doing standard builds, you know, dot slash configure, make, make, install,
etc. So it's important to when you're using cross tool ng to build your tool chain to actually
build it and install it where it's going to live for the rest of its life which in my case
was slash OPT slash tool chains slash ARMV7 for the ARM Cortex A7 tool chain.
A little bit about sort of doing this inside the chaotic order but a bit little bit about
compiling the kernel for a Raspberry Pi. This will give you a good demonstration of why you might want
to cross compile. When I first started fiddling about with Raspberry Pi's I compiled a kernel
on a Pi, an original 512 megabyte Model B Pi and it took 15 hours.
So I thought I don't want to do that again. So then I cross compiled originally using the
Raspberry Pi Foundation cross compiler tool chain and on my quad core machine which is 1.4 gigahertz
clock speed which is not mega fast and it's got 8 gigs around. The kernel compiled took 15
minutes so from 15 hours to 15 minutes. I could do 60 kernel compiles in a second time.
It's ridiculous. That's a very extreme example but you wouldn't want to spend your life
compiling a kernel on such a slow machine as a Raspberry Pi when with a little bit of effort
and help from a cross compiler tool chain you can do it much much more quickly.
There is another type of cross compiling activity which I will describe here for the sake of
completeness. I've not had to do this and I might have a go at doing it just for the experience but
this is called a Canadian build cross compile and what it is and you'll have to be patient
and think carefully here because it's quite complicated and straightforward cross compile.
Now suppose you wanted a cross compiler which would run on windows to create and to compile
and link code to run on a Raspberry Pi but you're going to create and build that tool chain,
that cross compiler tool chain on a Linux x8664. So there's three things involved.
Linux x8664 to make the tool chain which will run on windows which will compile and link code
to run on another platform like a Raspberry Pi. Three things this is called a Canadian build and the
reason it's called a Canadian build apparently is quite interesting is because at the time that that
name was coined the political landscape in Canada was dominated by three political parties so
some clever person termed it as a Canadian build. Now as I said I've never had to do that. I can't
think why I might have to do that although I might have a go at doing it with cross tool entry just
for the sake of finding out how to do it. It might be quite good fun. On the other hand it might be
a total brain aching experience. A few comments about the show notes. I've created a HTML version
of the show notes because they're 12 kilobytes, 12 kilobytes of show notes. Pretty comprehensive,
tells you all about why I've been doing this stuff, about how to install cross tool ng on Debian,
about how I configure where the cross tool ng tool will live and where the tool chains will live
and gives you details about why I've been doing this and there's a bunch of links and there's links to
clatus kernel compile show which was pretty good. Links to CTNG, cross tool ng, vagrant, virtual box,
arch Linux, ARM, Raspberry Pi website etc. So loads of links, loads of stuff.
There's also a dot tar dot gz file which contains the two dot config files for ARM V6 and ARM V7
which I grabbed from arch Linux ARM website and tinkered with to install the tool chain where I wanted it
and all of that is documented in the show notes. So if you just install cross tool ng the way I did
use the configuration files I use you should be able to end up with a cross tool,
cross compiler tool chain which will work and you should be able to compile code for
ARM Cortex A6 and ARM Cortex A7 both types of Raspberry Pi.
Audio, since my last show I've cranked down the microphone gain a little bit so hopefully
my siblings are not splitting your head wide open every time I say a word that begins with S.
I listen back to the recording so far and it sounds much better. I'm going to do a part two to
this and that will be setting up for an actual Raspberry Pi kernel compile using the cross
compiler tool chain that we built which I built which gave rise to this show. So that will be in a
while building the Raspberry Pi kernel on an arch Linux desktop, not an arch Linux, an X86, 64 desktop
machine, cross compiling the kernel run on Raspberry Pi. So there we go and in the next few days I
will possibly get around to doing that Raspberry Pi to first impressions show maybe.
You've been listening to Hecker Public Radio at Hecker Public Radio.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast then click on our contribute link to find out how
easy it really is. Hecker Public Radio was founded by the Digital Dove Pound and the
Infonomicon Computer Club and is part of the binary revolution at binrev.com. If you have
comments on today's show please email the host directly leave a comment on the website or record
a follow-up episode yourself. Unless otherwise status, today's show is released on the creative
comments, attribution, share a like, 3.0 license.