Cross-Compiling for Raspberry Pi

Index To the Series
1. Raspberry Pi likes Open Source
2. Cross-Compiling for Raspberry Pi
3. Cross-Compiling ITK for Raspberry Pi
4. Raspberry Pi likes VTK
5. Raspberry Pi likes Node.js


 Cross-Compiling for Raspberry Pi


Using a Dell Precision M6700 (Ubuntu 12.10) to build binaries for the Raspberry Pi


This is a follow up on our exploration of the Raspberry Pi.

Thanks to Andrew Maclean who generously shared with us his recipe to cross-compile for the Raspberry Pi in the comments of our previous blog.

Two of the main challenges with cross-compilation are that:

  • There are many ways to do it.
  • Recipes out there have some missing ingredients.

Here we are following Andrew’s recipe, and adding comments and small updates as we go about the process.

(Please share with us your variations, and improvements to this recipe).

 We are doing this in a DELL PRECISION M6700 Laptop running Ubuntu 12.10.


Note about the images in this blog post: We captured a good number of screenshots to document the process below. The images may appear in low resolution in the blog and may be hard to read, but if you click on them, you will get the full resolution image of the screenshot and text should appear very clearly on them.


Step 1. Build the Toolchain

Since we are going to run in laptop with an Intel processor, and we want to build object code for the ARM processor at the heart of the Raspberry Pi, we need a cross-compiler and its associated tools, which is usually called a “toolchain“. Here we are using “crosstool-ng” to build such tool chain.

Following Andrew’s advice, many of the instruction below follow this post by Chris Boot:


Step 1.1 Download crosstool-ng

We go to:

and download the most recent version, that at the time of writing this blog was:  1.17.0
note that in the download page, the version numbers are sorted alphabetically (not numerically).
In my first visit, I went straight to the bottom of the page and erroneously grabbed version 1.9.3,
just because it was at the bottom of the page…

This link below, with the downloads sorted by date, might be useful to you:

The file 00-LATEST-is-1.17.0 should have also be a hint… if I were paying attention…  🙂


We created a directory to host it and then downloaded and extracted the sources by doing:

  • mkdir -p  ~/src/RaspberryPi/toolchain
  • cd ~/src/RaspberryPi/toolchain
  • wget
  • tar xjf crosstool-ng-1.17.0.tar.bz2
  • cd crosstool-ng-1.17.0


Step 1.2 Configure and Build

Here we continue following Chris Boot’s instructions.

We chose to configure the tool to be installed in a local directory inside our home directory.

  • cd ~/src/RaspberryPi/toolchain/crosstool-ng-1.17.0
  • mkdir -p ~/local/crosstool-ng
  • ./configure –prefix=/home/ibanez/local/crosstool-ng

to get this to work, we had to install the following Ubuntu packages (most of which were listed in Andrew’s recipe),

  • bison
  • cvs
  • flex
  • gperf
  • texinfo
  • automake
  • libtool

The whole is done with the command:

  • sudo aptitude install bison cvs flex gperf texinfo automake libtool 

then we can do

  • make
  • make install

and add to the PATH the bin directory where crosstool-ng was installed:

  • export PATH=$PATH:/home/ibanez/local/crosstool-ng/bin/

In some cases, it might be necessary to unset the LD_LIBRARY_PATH,
to prevent the toolchain from grabbing other shared libraries from the host machine:



Step 1.3 Build Raspberry Toolchain

Create a staging directory. This is a temporary directory where the toolchain will be configured and built, but it is not its final installation place.

  • mkdir -p ~/src/RaspberryPi/staging
  • cd ~/src/RaspberryPi/staging/
  • ct-ng  menuconfig


You will see a menu similar to:

  • Go into the option “Paths and misc options”
  • Enable the option “Try features marked as EXPERIMENTAL”

  • In the option “Prefix Directory (NEW)”, one can set the actual destination directory where the toolchain will be installed.

  • In this case we choose to install in ${HOME}/local/x-tools/${CT_TARGET}.
    Others may prefer /opt/cross/x-tools/${CT_TARGET}, for example.

  • After you select < Ok >
  • Select the < Exit > option to go back to the main menu
  • There, select “Target options”.

  • Change the Target architecture to arm.

  • Leave Endianness set to Little endian and 
  • Bitness set to 32-bit.

  • Use again the < Exit > option to go back to the main menu
  • Select “Operating System”

  • There, change the “Target OS” option from (bare-metal)

  • to the option “linux”

  • Take the <Select> option
  • Use the < Exit > option to get back to the main menu
  • Select “Binary utilities”

  • Select “binutils version”

  • Take the most recent version that is not marked as EXPERIMENTAL.
    In our case, that was version 2.21.1a

  • Go back to the main menu
  • Select “C compiler”

  • Enable the Show Linaro versions (EXPERIMENTAL) option.

  • Here we selected the “linaro-4.7-2012.10 (EXPERIMENTAL) “
    This is a bit newer than the version “linaro-4.6-2012.04 (EXPERIMENTAL)”
    that Chris Boot was using in his blog post, so here we are taking our chances…

  • Select that option.
  • Exist the configuration and
  • Save the changes

Note contributed by Scott Determan:

If you want to cross-compile code that used C++11 futures/promises,
then gcc needs to be build with the flag


To do this, use the command

            ct-ng menuconfig,

and go to the item:

       Target options -> Architecture level

and set it to “armv6” (without quotes),

then you will be able to cross compile code that uses futures/promises.


Thanks Scott !

 Then, start the build process by typing

  • ct-ng  build

  • It was nice to see that the build projects uses the proper “make -j ” options for parallel building
    and therefore makes use of all the available cores:

Not to be a whiner…. but,…
the problem with this,
is that it only gives us 18minutes and 9 seconds for the Coffee break   🙂

  • When the build process finishes, we end up with the toolchain installed in the “prefix” directory.
    In our case: ${HOME}/local/x-tools/${CT_TARGET}
  • More specifically:
  • Where we will find the following collection of executables in the “bin” directory:

  • We now add this directory to the PATH:
    export PATH=$PATH:/home/ibanez/local/x-tools/arm-unknown-linux-gnueabi/bin
  • We can then test the toolchain with a “hello world” small C program.
  • Compiling it locally as “helloworld” (in “aleph” which is the name of our Ubuntu Laptop).
  • Then copying it into the Raspberry Pi
  • and finally running it there


Step 1.4 Build the C++ compiler in the toolchain

By default, our process above only built the C compiler.

We are now going to build the C++ compiler as well.

To build the C++ compiler we do the following:

  • We go back to the staging directory:
  • and run the configuration process
    ct-ng menuconfig

  • We go into the “C compiler” option

  • Enable the option “C++”

  • Save and Exit
  • and type again
       “ct-ng  build”
    to build the toolchain.

This time it took 13 minutes 18 seconds

and we have now the new C++ components in the toolchain binary directory

 Time to test the C++ compiler with a Hello World.

  • We build it locally
  • Copy the executable to the Raspberry Pi
  • Login in the Raspberry Pi
  • Execute the cross-compiled executable

This completes the set up of the tool chain.

We are now ready to use CMake to cross compile bigger projects.





Step 2. One CMake File to Rule Them All !

We now turn our attention to the Cross Compilation instructions of the CMake Wiki

The first step here is to write a .cmake file that points to the toolchain.

In our case we choose to call this file:

  • Toolchain-RaspberryPi.cmake

and put on it the following content


# this one is important
#this one not so much

# specify the cross compiler


# where is the target environment

# search for programs in the build host directories
# for libraries and headers in the target directories

Note here that the path

  • /home/ibanez/local/x-tools/arm-unknown-linux-gnueabi

is the base directory where we installed the toolchain.

and the file names

  • arm-unknown-linux-gnueabi-gcc
  • arm-unknown-linux-gnueabi-g++

are the names of the generated C and C++ compilers respectively.


We now put the cmake toolchain file in the directory:

  • /home/ibanez/bin/RaspberryPi/CMakeToolChain

Then we create a CMake-based Hello World example:

  • mkdir -p /tmp/hello/src
  • mkdir -p /tmp/hello/bin
  • cd /tmp/hello/src

write here a CMakeLists.txt file with just:

cmake_minimum_required(VERSION 2.8)
add_executable(HelloWorld HelloWorld.cxx )

and the associated HelloWorld.cxx file with:

#include <iostream>
int main() {
  std::cout << “Hello World++ !” << std::endl;
  return 0;

Then, we can change directories to the bin directory and configure with CMake, by pointing to the toolchain file as:

  • cd /tmp/hello/bin
  • cmake -DCMAKE_TOOLCHAIN_FILE=/home/ibanez/bin/RaspberryPi/CMakeToolChain/Toolchain-RaspberryPi.cmake ../src
  • and simply build with “make”
  • Then copy the resulting executable to the Raspberry Pi, and run it.


Step 3. Setting up additional bin and lib files for cross compiling.

If you need access to the libraries on the RaspberryPi for compiling
(for example if you have built the latest boost libriaries on the RaspberryPi
and it is installed in /usr/local), you can copy these to a directory on your
host computer using rsync that will preserve the symlinks.
  • On your host machine you may also have to install rsync
    •  sudo aptitude install rsync
  • On the RaspberryPi install rsync:
    •  sudo apt-get istall rsync
  • Create a folder on the cross compiling machine. For example, here we call it: ~/bin/RaspberryPi
    • mkdir -p ~/bin/RaspberryPi
  • cd to this folder
    • cd  ~/bin/RaspberryPi
  • and do the following:
    • rsync -rl pi@raspberrypi.bigpond:/lib .
    • rsync -rl pi@raspberrypi.bigpond:/usr .

Remember to run these rsync commands whenever new libraries are added to the RaspberryPi system or when the RaspberryPi is upgraded.



This concludes our introduction to Cross Compilation for the Raspberry Pi using CMake.


Please share with us your comments, and suggestions for improving this process.

25 Responses to Cross-Compiling for Raspberry Pi

  1. Will Schroeder says:

    Check this out, there are other alternatives to Raspberry Pi:
    Raspberry Pi vs MK802 II

  2. Emilian Mihalache says:

    Hi, thanks for the article.

    When compiling the C++ toolchain, I got an error: .build/src/gcc-linaro-4.7-2013.01/gcc/tree-ssa-ccp.c:1335:43: error: ‘r1vam’ undeclared (first use in this function)

    I checked the file on the Linaro repo, and saw that on line 1335,

    maxmin = double_int_cmp (double_int_ior (r1vam, r1mask),
    double_int_and_not (r2val, r2mask), uns);
    should be

    maxmin = double_int_cmp (double_int_ior (r1val, r1mask),
    double_int_and_not (r2val, r2mask), uns);

    I’m not sure why my file got ‘corrupted’, I just thought I should mention this for other people to check before starting the compilation (I was about 22 minutes in when this error occured).

    Compilation worked fine after correcting the apparent syntax error.

  3. Roland Ohlsson says:

    I have followed the guide, but get the following error when i run the configure file:

    checking for libintl.h… yes
    checking whether gettext is declared… yes
    checking ncurses/ncurses.h usability… no
    checking ncurses/ncurses.h presence… no
    checking for ncurses/ncurses.h… no
    checking ncurses/curses.h usability… no
    checking ncurses/curses.h presence… no
    checking for ncurses/curses.h… no
    checking ncursesw/curses.h usability… no
    checking ncursesw/curses.h presence… no
    checking for ncursesw/curses.h… no
    checking ncurses.h usability… no
    checking ncurses.h presence… no
    checking for ncurses.h… no
    checking curses.h usability… no
    checking curses.h presence… no
    checking for curses.h… no
    configure: error: could not find curses header, required for the kconfig frontends

    Any idea how to solve it? I tested to change the prefix to my own direction, but the same error occured

  4. Roland Ohlsson says:

    I mean i run this part of the tutorial:
    ./configure –prefix=/home/ddskroh/local/crosstool-ng

  5. says:

    Very nice guide.
    I ran into a problem at the ct-ng build step. I got the following error message:

    ct-ng could not retrieve eglibc-2_17

    The problem was caused by not having subversion installed.

    It was fixed by:
    sudo apt-get install subversion

  6. Yaiza Vi says:

    First of all thank you for this tutorial, you have explained everything very well.
    I have a problem at here:
    “Time to test the C++ compiler with a Hello World…
    Execute the cross-compiled executable”
    In the last step I can’t execute it in Raspberry, it gives the error “No such file or directory”. Do you know a solution?, because the file is in the correct folder, so I can’t understand it

  7. Yaiza Vi says:

    I have solved it, I think that it was a problem with the architecture
    Thank for your time and Congratulations for this guide

  8. Luis Ibanez says:


    Thanks for sharing the update and how you solved the problem.

    Please let us know about what you do with the Raspberry Pi !


  9. Martin Runge says:


    I would like to suggest two additions to this approach:

    – I have had problem linking “more advanced” c++ libraries when using gcc-4.7 for cross compiling. Raspbian used gcc 4.6.3. Using exactly the same version made these linker problems go away.

    – Raspbian is based on Debian which uses the mutli arch directory layout for libraries. E.g. some libraries expected in /usr/lib are in /usr/lib/arm-linux-gnueabihf/ instead. GCC on debian is patched to search these directories by default, too, but the cross compiler built by ct-ng isn’t yet. I got around this with a special toolchain file (at least when using cmake):

    I included following in the toolchain file:

    set(CMAKE_LIBRARY_ARCHITECTURE arm-linux-gnueabihf)

    so find_package will search these subfolders, too. Additionally, I set



    A patched cross gcc would be nicer of cause, then all the CMake stuff can be straightforward again, like described in this blog 🙂

  10. Muhammad Khan says:

    I am new here struggling with the building of cross compiler. I have followed this page, after running the following command i got the error

    ct-ng build

    Debugging detail is also attach with full detail.

    [DEBUG] Not at this location: “”
    [ERROR] >>
    [ERROR] >> Build failed in step ‘Retrieving needed toolchain components’ tarballs’
    [ERROR] >> called in step ‘(top-level)’
    [ERROR] >>
    [ERROR] >> Error happened in: do_kernel_get[scripts/build/kernel/]
    [ERROR] >> called from: main[scripts/]
    [ERROR] >>
    [ERROR] >> For more info on this error, look at the file: ‘build.log’
    [ERROR] >> There is a list of known issues, some with workarounds, in:
    [ERROR] >> ‘/home/arslan/local/crosstool-ng/share/doc/crosstool-ng/ct-ng.1.17.0/B – Known issues.txt’
    [ERROR] (elapsed: 19:15.76)

    Kindly Guide me what I have to do now? Your suggestion will be highly appreciated.

  11. Kaveendra Vithana says:

    @Roland Ohlsson

    It requires ncurses.h file, so if on fedora, yum install ncurses* will get you what’s missing

  12. Luis Ibanez says:


    Thanks for sharing the solution !


  13. Scott Determan says:

    Hi Luis,

    This page worked great for me – thank you! I did have one issue: I was unable to x-compile code that used C++11 futures/promises. To use these, gcc needs to be build with the flag –with-arch=armv6.

    In ct-ng menuconfig, if I go to the item: Target options -> Architecture level, and set it to “armv6” (without quotes), then I am able to cross compile code that uses futures/promises.

    Thought I would leave a comment here in case anyone else encounters the same problem (or you want to change these instructions).

    Thanks again for documenting the x-compile process!

  14. Luis Ibanez says:

    Hi Scott,

    Many thanks for sharing this finding about C++11.

    I have now added your comment in the section on how to build the C++ compiler (it is now in a blue box comment).

    Please keep all this good stuff coming !



  15. Scott Determan says:

    Hi Luis,

    Just a quick note on the setting the architecture level. I set it at the very beginning of the build process. I’m not sure what will happen if you make the change after you build the C compiler (as currently specified in your notes). I’m guessing it will rebuild, so people would have to take two long coffee breaks.

    I understand why you put it in the C++ section, but I would recommend putting it earlier in the build process.


  16. Luis Ibanez says:

    Hi Scott,

    Thanks for pointing that out. I have now moved your note to the end of the configuration of the C compiler. Just before starting the build.

    Please let me know if you see anything else that can be improved.


  17. Vygantas Mikalajunas says:


    Getting this ugly error when I am running “ct-ng build”:

    [INFO ] Installing PPL for host
    [ERROR] /root/src/RaspberryPi/staging/.build/src/ppl-0.11.2/src/mp_std_bits.defs.hh:48:7: error: redefinition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/arm-unknown-linux-gnueabi/buildtools/include/gmpxx.h:3269:21: error: previous definition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/src/ppl-0.11.2/src/mp_std_bits.defs.hh:109:7: error: redefinition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/arm-unknown-linux-gnueabi/buildtools/include/gmpxx.h:3306:21: error: previous definition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/src/ppl-0.11.2/src/mp_std_bits.defs.hh:48:7: error: redefinition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/arm-unknown-linux-gnueabi/buildtools/include/gmpxx.h:3269:21: error: previous definition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/src/ppl-0.11.2/src/mp_std_bits.defs.hh:109:7: error: redefinition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/arm-unknown-linux-gnueabi/buildtools/include/gmpxx.h:3306:21: error: previous definition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/src/ppl-0.11.2/src/mp_std_bits.defs.hh:48:7: error: redefinition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/arm-unknown-linux-gnueabi/buildtools/include/gmpxx.h:3269:21: error: previous definition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/src/ppl-0.11.2/src/mp_std_bits.defs.hh:109:7: error: redefinition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/arm-unknown-linux-gnueabi/buildtools/include/gmpxx.h:3306:21: error: previous definition of ‘class std::numeric_limits’
    [ERROR] make[4]: *** [Checked_Number.lo] Error 1
    [ERROR] /root/src/RaspberryPi/staging/.build/src/ppl-0.11.2/src/mp_std_bits.defs.hh:48:7: error: redefinition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/arm-unknown-linux-gnueabi/buildtools/include/gmpxx.h:3269:21: error: previous definition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/src/ppl-0.11.2/src/mp_std_bits.defs.hh:109:7: error: redefinition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/arm-unknown-linux-gnueabi/buildtools/include/gmpxx.h:3306:21: error: previous definition of ‘class std::numeric_limits’
    [ERROR] make[4]: *** [checked.lo] Error 1
    [ERROR] /root/src/RaspberryPi/staging/.build/src/ppl-0.11.2/src/mp_std_bits.defs.hh:48:7: error: redefinition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/arm-unknown-linux-gnueabi/buildtools/include/gmpxx.h:3269:21: error: previous definition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/src/ppl-0.11.2/src/mp_std_bits.defs.hh:109:7: error: redefinition of ‘class std::numeric_limits’
    [ERROR] /root/src/RaspberryPi/staging/.build/arm-unknown-linux-gnueabi/buildtools/include/gmpxx.h:3306:21: error: previous definition of ‘class std::numeric_limits’
    [ERROR] make[4]: *** [Constraint.lo] Error 1
    [ERROR] make[4]: *** [Constraint_System.lo] Error 1
    [ERROR] make[4]: *** [Box.lo] Error 1
    [ERROR] make[3]: *** [all] Error 2
    [ERROR] make[2]: *** [all-recursive] Error 1
    [ERROR] make[1]: *** [all] Error 2
    [ERROR] >>
    [ERROR] >> Build failed in step ‘Installing PPL for host’
    [ERROR] >> called in step ‘(top-level)’
    [ERROR] >>
    [ERROR] >> Error happened in: CT_DoExecLog[scripts/functions@257]
    [ERROR] >> called from: do_ppl_backend[scripts/build/companion_libs/]
    [ERROR] >> called from: do_ppl_for_host[scripts/build/companion_libs/]
    [ERROR] >> called from: do_companion_libs_for_host[scripts/build/]
    [ERROR] >> called from: main[scripts/]
    [ERROR] >>

    Have installed libgmp3-dev with no result.


  18. Godfrey Godwin says:

    I the last step when I try to do the following:
    rsync -rl pi@raspberrypi.bigpond:/lib .
    rsync -rl pi@raspberrypi.bigpond:/usr .

    ssh: Could not resolve hostname Name or service not known
    rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
    rsync error: unexplained error (code 255) at io.c(605) [Receiver=3.0.9]

  19. Luis Ibanez says:


    the command should be only

    rsync -rl pi@raspberrypi:/lib .

    (no “bigpond”,… that was only an example of a domain)

    or to be more explicit, put the IP address of your raspberrypi.

    It should look like:

    rsync -rl pi@ .

    but, of course, with your actual IP address, instead of the example “”.

    More on rsync here:

  20. Steve Hansen says:

    This is an excellent tutorial!

    I had to also install:

  21. Al Bdx says:


    I managed to get the C compiler work following the example, but I cannot check the “C++” checkbox in C Compiler -> C++ and do the second part of the tutorial. Any idea why?

  22. Davood Falahati says:

    Please note that in a fresh distribution of Ubuntu/Mint you need to install curses5-dev to alleviate cmake nagging for not founding curses headers. In other words, you need to do this:
    sudo apt-get install bison cvs flex gperf texinfo automake libtool curses5-dev

    ./configure –prefix=/home/src/

    sudo make install
    export PATH=”${PATH}:/home/src/bin”

  23. Bem says:

    I am using crosstool-ng 1.23.0.rc2 for cross compilation.

    Followed the steps:
    $ sudo apt-get install gperf bison flex makeinfo texinfo help2man ncurses-dev
    $ mkdir -p ~/src/toolchain
    $ ~/src/toolchain/
    $ wget
    $ tar xjf crosstool-ng-1.23.0.rc2.tar.bz2
    $ cd crosstool-ng-1.23.0.rc2/
    $ mkdir -p ~/local/crosstool-ng
    $ ./configure –prefix=/home/iiitd/local/crosstool-ng
    $ make
    $ sudo make install
    $ sudo cp ct-ng.comp /etc/bash_completion.d/
    $ export PATH=$PATH:/home/iiitd/local/crosstool-ng/bin
    $ mkdir -p ~/src/staging
    $ cd ~/src/staging/
    $ ct-ng menuconfig

    In the menuconfig interface I have done the following changes:

    Enable “Try features marked as EXPERIMENTAL”

    Set the “Prefix directory” from “${HOME}/x-tools/${CT_TARGET}” to “${HOME}/local/x-tools/${CT_TARGET}”

    “Target Architecture” is set to “arm”
    “Little Endian” and “32bit” are selected
    “Use EABI” is selected

    “Target OS” to Linux

    Enable “Show Linaro versions”
    Enable “C++” in order to have C++ compiler

    Save and Exit

    $ ct-ng build

    .config: line 526: unexpected EOF while looking for matching `”‘
    .config: line 534: syntax error: unexpected end of file
    [ERROR] >>
    [ERROR] >> Build failed in step ‘(top-level)’
    [ERROR] >>
    [ERROR] >> Error happened in: CT_LoadConfig[scripts/functions@15]
    [ERROR] >> called from: main[scripts/]
    [ERROR] >>
    [ERROR] >> There is a list of known issues, some with workarounds, in:
    [ERROR] >> ‘/home/iiitd/local/crosstool-ng/share/doc/crosstool-ng/crosstool-ng-1.23.0-rc2/B – Known issues.txt’
    [ERROR] (elapsed: 24863888:00.96)
    /home/iiitd/local/crosstool-ng/bin/ct-ng:147: recipe for target ‘build’ failed
    make: *** [build] Error 1

  24. Great article. Everything seems to work pretty well, except (and this is more of a CMake question),,, could you elaborate a bit more on the Toolchain file – specifically how to get cmake to look for the RPi libs and headers in the correct library while using the intel based cross compile executables?

Questions or comments are always welcome!