Project

General

Profile

Cross compile Wt on Raspberry Pi » History » Version 2

Shantanu Tushar, 05/10/2014 08:00 AM
BUILD_SHARED_LIBS didn't work for me, SHARED_LIBS works

1 1 Wim Dumon
h1. Cross compile Wt on Raspberry Pi
2
3
While the Raspberry Pi looks is a complete computer with a full debian distribution, it has a slow flash disk, limited memory, and CPU power under it's hood. Compiling Wt on the device itself is not recommended unless you have a lot of time. The method described here allowed us to cross compile Wt for Raspbian GNU/Linux 7. This guide assumes that Raspbian is installed on your raspberry pi.
4
5
Note that wt packages are available on the raspbian, so you don't even have to cross-compile Wt is you're ok with the version of Wt included in your raspbian distribution. Just apt-get install it: @apt-get install witty witty-dev witty-doc witty-dbg witty-examples@
6
7
For embedded deployment, we highly recommend to cross-compile Wt. Wt supports cross-compilation, and we were successful in cross-compiling Wt on the Raspberry Pi using the method described below.
8
9
The general idea is to install a cross-compiler on your host, and the development libraries on the raspberry. Using sshfs, we will compile on the host, using the cross compiler on the host, and the header files on the raspberry pi. The resulting executables can then be copied to the raspberry pi and executed there.
10
11
The instructions below can be used to cross-compile anything that uses cmake, not just Wt. It's also recommended to cross-compile your own applications, you'll notice that it's much faster than compiling on the device itself.
12
13
h2. Install prerequisites on the raspberry pi
14
15
Log in on your raspberry pi and install the desired dependencies. To build Wt, boost is actually the only required dependency:
16
<pre>
17
# log in on the rpi to install the dependency libraries
18
ssh pi@raspberrypi
19
sudo apt-get install libboost-all-dev
20
</pre>
21
22
h2. Install cross compilation tool chain:
23
24
Ideally, raspbian should distribute cross-compilers for their distribution, but as far as I know, they don't. Building a correct, working cross compilation from scratch, even with tools like crosstool-ng, is a challenge in itself and many guides on the internet are either out-dated, flawed, or fail to produce the tools. We did not easily succeed to use crosstool-ng to generate a cross-compilation environment for the same gcc and glibc version as installed on our raspberry pi.
25
26
We finally used a pre-built cross compilation tool chain for a slightly different version of gcc and libc:
27
<pre>
28
# make sure that you've logged out from your rpi, execute these commands in on your host computer:
29
mkdir ~/rpi
30
git clone https://github.com/raspberrypi/tools.git
31
</pre>
32
33
h2. Make raspberry pi development files (header files, libraries) available on the host
34
35
On your cross compilation host, use sshfs to mount your complete raspberry pi:
36
<pre>
37
# make sure that you've logged out from your rpi, execute these commands in on your host computer:
38
mkdir ~/mnt_rpi
39
sshfs pi@rspberrypi:/ ~/mnt_rpi/ -o transform_symlinks
40
</pre>
41
42
The @-o transform_symlinks@ is required to transform absolute symlinks on the rpi to relative ones, so that a link on the rpi filesystem to /lib/libabc.so actually still points to the same file, and not to /lib/libabc.so on the host filesystem.
43
44
*Imporant note:* on the raspbian distribution we used, we ran into a second form of 'links' to absolute paths that prevented linking to work out of the box (resulting in link errors for libpthread, libc, libc_nonshared, ...). The files @/usr/lib/arm-linux-gnueabihf/libc.so@ and @/usr/lib/arm-linux-gnueabihf/libpthread.so@ are actually linker scripts that refer to absolute paths, which are not correct when cross compiling. Our solution was to remove the absolute path from the linker script.
45
46
For example:
47
<pre>
48
/* GNU ld script
49
   Use the shared library, but some functions are only in
50
   the static library, so try that secondarily.  */
51
OUTPUT_FORMAT(elf32-littlearm)
52
GROUP ( /lib/arm-linux-gnueabihf/libc.so.6 /usr/lib/arm-linux-gnueabihf/libc_nonshared.a  AS_NEEDED ( /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ) )
53
</pre>
54
becomes:
55
<pre>
56
/* GNU ld script
57
   Use the shared library, but some functions are only in
58
   the static library, so try that secondarily.  */
59
OUTPUT_FORMAT(elf32-littlearm)
60
GROUP ( libc.so.6 libc_nonshared.a  AS_NEEDED ( ld-linux-armhf.so.3 ) )
61
</pre>
62
63
This modification solves the problem and is, as far as we know, otherwise harmless.
64
65
h2. Make a cmake toolchain file for cross compilation
66
67
Create the file below, and save it on your host computer as @~/rpi-toolchain.cmake@.
68
69
Replace @/home/me@ in the file below by your own home directory.
70
71
<pre>
72
SET(CMAKE_SYSTEM_NAME Linux)
73
SET(CMAKE_SYSTEM_VERSION 1)
74
75
SET(CMAKE_C_COMPILER
76
/home/me/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc)
77
78
SET(CMAKE_CXX_COMPILER
79
/home/me/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++)
80
81
# where is the target environment - we mounted it using sshfs
82
SET(CMAKE_FIND_ROOT_PATH /home/me/mnt_rpi)
83
84
# search for programs in the build host directories
85
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
86
# for libraries and headers in the target directories
87
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
88
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
89
</pre>
90
91
h2. Cross compile Wt
92
93
Once the cross compilation environment is set up, compiling Wt is straight forward:
94
<pre>
95
# make sure that you've logged out from your rpi, execute these commands in on your host computer:
96
# untar wt: tar xvzf wt-x.y.z.tar.gz
97
cd wt-x.y.z
98
mkdir build-rpi
99
cd build-rpi
100 2 Shantanu Tushar
cmake ../wt -DCMAKE_TOOLCHAIN_FILE=~/rpi_toolchain.cmake -DSHARED_LIBS=OFF
101 1 Wim Dumon
make -j 8
102
cd examples
103
make -j 8
104
</pre>
105 2 Shantanu Tushar
The SHARED_LIBS=OFF option makes the Wt libraries static. This is not required, but easier for deployment: you can simply copy the example executables to your raspberry pi without having to worry about the shared libraries.
106 1 Wim Dumon
107
h2. Run hello world on the Raspberry Pi
108
109
<pre>
110
# log in on the rpi and execute hello world
111
scp examples/hello/hello.wt pi@raspberrypi:
112
ssh pi@raspberrypi
113
chmod +x hello.wt
114
./hello.wt --docroot . --http-address 0.0.0.0 --http-port 8080
115
</pre>
116
Now surf to your raspberrypi (http://raspberrypi:8080/) from your host computer and you should see the hello world application!