Michael Zucchi

 B.E. (Comp. Sys. Eng.)

  also known as zed
  & handle of notzed


android (44)
beagle (63)
biographical (103)
blogz (9)
business (1)
code (74)
compilerz (1)
cooking (31)
dez (7)
dusk (31)
extensionz (1)
ffts (3)
forth (3)
free software (4)
games (32)
gloat (2)
globalisation (1)
gnu (4)
graphics (16)
gsoc (4)
hacking (455)
haiku (2)
horticulture (10)
house (23)
hsa (6)
humour (7)
imagez (28)
java (231)
java ee (3)
javafx (49)
jjmpeg (81)
junk (3)
kobo (15)
libeze (7)
linux (5)
mediaz (27)
ml (15)
nativez (10)
opencl (120)
os (17)
panamaz (5)
parallella (97)
pdfz (8)
philosophy (26)
picfx (2)
players (1)
playerz (2)
politics (7)
ps3 (12)
puppybits (17)
rants (137)
readerz (8)
rez (1)
socles (36)
termz (3)
videoz (6)
vulkan (3)
wanki (3)
workshop (3)
zcl (4)
zedzone (24)
Sunday, 06 April 2014, 12:33

linaro arm gnueabihf cross compilers on Slackware64

I've been trying to get a full cross compilation setup going for the parallella but had way more trouble than I should have getting the cross compiler for arm going. I'm using the linaro sources but can't use the binaries I saw because Slackware64 isn't setup for multilib by default and I didn't want to turn it on. It turned out to be easy but I kept getting wrong arguments from old web pages or got the wrong info from others that weren't doing quite the same thing.

It's very well possible there are binaries elsewhere but I didn't see them; and in any case getting this to work is a lot more useful for me. The linaro build tool 'crosstool-ng' seems to expect debian and/or ubuntu and simply didn't work.

I started from linaro-toolchain-binaries page, and downloaded the full sources sources part 1 and part 2 (although part2 is just the linux kernel source which isn't necessary).

First, some variables/setup which makes it work:

mkdir -p ${prefix}
export PATH=${PATH}:${prefix}/bin

prefix is the install location.

tar xvjf ~/Downloads/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_src-part1.tar.bz2 

Then untar the interesting ones in a way that the configure scripts expect. I use a script for this but this is what it executes:

mkdir -p build
tar xJf gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_src/gcc-linaro-4.8-2013.10.tar.xz -C build
mv build/gcc-linaro-4.8-2013.10 build/gcc-linaro
tar xjf gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_src/binutils-linaro-2.23.2-2013.10-4.tar.bz2 -C build
mv build/binutils-linaro-2.23.2-2013.10-4 build/binutils-linaro
tar xjf gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_src/linaro-prebuilt-sysroot-2013.10.tar.bz2 -C ${prefix}
tar xjf gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_src/gmp-5.0.2.tar.bz2 -C build
ln -s ../gmp-5.0.2 build/gcc-linaro/gmp
tar xzf gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_src/mpc-0.9.tar.gz -C build
ln -s ../mpc-0.9 build/gcc-linaro/mpc
tar xJf gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_src/mpfr-3.1.0.tar.xz -C build
ln -s ../mpfr-3.1.0 build/gcc-linaro/mpfr
tar xzf gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_src/zlib-1.2.5.tar.gz -C build
ln -s ../zlib-1.2.5 build/gcc-linaro/zlib


Then the building, just two stages: binutils then gcc. The sysroot from linaro is used and contains libc and so on.

Binutils is straightforward and only takes a minute or so to build.

mkdir -p ${top}/build/binutils-build
cd ${top}/build/binutils-build
../binutils-linaro/configure \
 --prefix=${prefix} \
 --target=arm-linux-gnueabihf \
 --disable-nls --disable-werror \
make -j8
make install

Then gcc. This was the painful one ... but to cut the long story short this is what I did to get it to work. It takes a few minutes to build.

mkdir -p ${top}/build/gcc-build
cd ${top}/build/gcc-build
../gcc-linaro/configure \
 --prefix=${prefix} \
 --host=x86_64-linux-gnu \
 --build=x86_64-linux-gnu \
 --target=arm-linux-gnueabihf \
 --with-float=hard --with-arch=armv7-a -with-fpu=vfpv3-d16 \
 --disable-nls --disable-werror \
 --enable-languages=c,c++ \
make -j8
make install

*shrug* I can't really say whether it's right or wrong but - but it worked well enough to cross compile a working binary.

The ezesdk

So mostly why I did this was so that I could do some re-arranging of the elf-loader code into a more wide-reaching library and keep working on it locally on my workstation rather than having to do it on the parallella. Not that it isn't fast enough to do the little bit of compiling I need - it certainly is - it was just all done on a whim really (one that drew out to a good few hours although not particularly intense ones, in between making another batch of biltong, cooking some corned beef, drinking, and surfing the web).

Another whimsical decision was to fork the epiphany e-hal library. This ... isn't really something I originally intended to do because it just means more to maintain and also there may be future functionality that would be best kept there - such as multi-process arbitration and so forth. But I guess one small but real justification is that right now I need to access some private (-local) data structures which are presumably 'private' for a reason; and if they ever really went private things would break.

Anyway ... I've just been extremely tired the last few days and a bit distracted by some stuff (to somewhat understate it) so it may well just be a bad idea but I suppose i'll see how far I get. It's taken long enough just to decide on a directory layout. At this point i'm going to have libezehost.so which will be the host driver (e-hal + elf-loader, etc), and libezecore.a which will be the on-core api (i.e. e-lib equivalent) although much of it is inline.

I unfortunately have to start working on that other project tomorrow which means a long commute on cyclist hostile roads (more so than average) so tonight better be an early one. Just as well i'm totally knackered and might not even make 10pm - although daylight saving just ended today so it's "really" later than that.

Tagged parallella.
developer tools and tasks vs non-developer tools and tasks | Quick swing by JavaFX
Copyright (C) 2019 Michael Zucchi, All Rights Reserved. Powered by gcc & me!