Project

General

Profile

Cross compile Wt on Raspberry Pi » History » Version 4

Wim Dumon, 04/18/2017 05:39 PM

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 4 Wim Dumon
h2. Make raspberry pi development files (header files, libraries) available on the host
34 3 Checheta Yan
35 1 Wim Dumon
36
On your cross compilation host, use sshfs to mount your complete raspberry pi:
37
<pre>
38
# make sure that you've logged out from your rpi, execute these commands in on your host computer:
39
mkdir ~/mnt_rpi
40
sshfs pi@rspberrypi:/ ~/mnt_rpi/ -o transform_symlinks
41
</pre>
42
43
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.
44
45
*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.
46
47
For example:
48
<pre>
49
/* GNU ld script
50
   Use the shared library, but some functions are only in
51
   the static library, so try that secondarily.  */
52
OUTPUT_FORMAT(elf32-littlearm)
53
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 ) )
54
</pre>
55
becomes:
56
<pre>
57
/* GNU ld script
58
   Use the shared library, but some functions are only in
59
   the static library, so try that secondarily.  */
60
OUTPUT_FORMAT(elf32-littlearm)
61
GROUP ( libc.so.6 libc_nonshared.a  AS_NEEDED ( ld-linux-armhf.so.3 ) )
62
</pre>
63
64
This modification solves the problem and is, as far as we know, otherwise harmless.
65
66
h2. Make a cmake toolchain file for cross compilation
67
68
Create the file below, and save it on your host computer as @~/rpi-toolchain.cmake@.
69
70
Replace @/home/me@ in the file below by your own home directory.
71
72
<pre>
73
SET(CMAKE_SYSTEM_NAME Linux)
74
SET(CMAKE_SYSTEM_VERSION 1)
75
76
SET(CMAKE_C_COMPILER
77
/home/me/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc)
78
79
SET(CMAKE_CXX_COMPILER
80
/home/me/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++)
81
82
# where is the target environment - we mounted it using sshfs
83
SET(CMAKE_FIND_ROOT_PATH /home/me/mnt_rpi)
84
85
# search for programs in the build host directories
86
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
87
# for libraries and headers in the target directories
88
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
89
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
90
</pre>
91
92
h2. Cross compile Wt
93
94
Once the cross compilation environment is set up, compiling Wt is straight forward:
95
<pre>
96
# make sure that you've logged out from your rpi, execute these commands in on your host computer:
97
# untar wt: tar xvzf wt-x.y.z.tar.gz
98
cd wt-x.y.z
99
mkdir build-rpi
100
cd build-rpi
101 2 Shantanu Tushar
cmake ../wt -DCMAKE_TOOLCHAIN_FILE=~/rpi_toolchain.cmake -DSHARED_LIBS=OFF
102 1 Wim Dumon
make -j 8
103
cd examples
104
make -j 8
105
</pre>
106 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.
107 1 Wim Dumon
108
h2. Run hello world on the Raspberry Pi
109
110
<pre>
111
# log in on the rpi and execute hello world
112
scp examples/hello/hello.wt pi@raspberrypi:
113
ssh pi@raspberrypi
114
chmod +x hello.wt
115
./hello.wt --docroot . --http-address 0.0.0.0 --http-port 8080
116
</pre>
117
Now surf to your raspberrypi (http://raspberrypi:8080/) from your host computer and you should see the hello world application!