Cross-compilation & Distributed compilation for the Raspberry Pi

Introduction

Compiling large programs such as a Linux Kernel, or big libraries like OpenCV, OpenNI directly on your Raspberry Pi will take a lot of time, and sometimes will even fail ( I was not able to reach more than 6% in the compilation process of the PCL, when compiling directly on the Pi ).

In this howto I will show you how to:

  1. cross compile programs, i.e.: how you can compile a program on your PC so that it will run on your Raspberry Pi
  2. distribute the compilation so that when you compile a program from your Raspberry Pi it actually gets cross-compiled on your remote PC(s), in a totally transparent manner

 

I am assuming that just as me, you're manipulating directly in your $HOME directory, both on your Raspberry Pi and your PC, running any Debian-flavored Linux distribution ( Debian, Linux Mint Debian Edition, Ubuntu... ). However, adapting this tutorial to your non-Debian distribution should not be too complicated, just use the equivalent packages you will find in your package manager.

1 - Install a toolchain

To cross compile you have to set up a toolchain. You have two options here:

  1. build it yourself
  2. use the one provided by the Raspberry Pi Foundation
Use the first option if you are curious and want to learn how to build your own toolchain using crosstool-ng, or use the second one to save you some time and be sure to end-up with something working.
Note: this part is happening on your Linux PC, not on the Raspberry Pi !
1.1 - Build your toolchain
TODO

 

 

 

 

Before I finish to write this paragraph, you can find good materials to build your own toolchain here.

1.2 - Using the official Raspberry Pi Toolchain

The Raspberry Pi Foundation is providing a ready-to-use toolchain on their github repository. You can use it to save yourself some time.

To do so, you need to have git installed and to clone the repository :

The "--depth=1" is here to tell git we only want the last revision, and not the whole history to be cloned.

Assuming you use Raspbian, issue a:

Here are the binaries we will use to cross-compile. Let's test them !

Create a new file named hello_world.c and copy/paste the following code:

Then, enter the following commands:

As you see, you can't execute this program on your PC. The file command tells you that this executable is built for ARM processors.

Now, copy your hello_world file on your Raspberry Pi :

Congratulations, you just cross-compiled your first Raspberry-Pi program !

Now, you can develop your programs and compile them directly on your PC, then upload them on your Pi and voilà, everything should work !

But now imagine you want to cross-compile a library that depends on other librairies (which, in turn, could depend on other libraries...). How will you do to satisfy these dependencies? Having the libraries installed on your PC won't work, because they are compiled to run on a non-ARM architecture ( probably x86 x86_64 ).

Plus, imagine you have several PC's and you would like to share the cross-compilation tasks among each of them to speed-up the process. Wouldn't it be awesome? ( I confess this "compilation farm" functionality is the one that I like the most =) ).

And wouldn't it be nice if you were able to do all this from your Raspberry Pi? Just launching the make command, having your remote PC's working instead of your Pi, and a few seconds later having your program/library compiled just as if everything happened on the Pi itself?

This is possible using distcc, a tool to distribute builds of C, C++... accross several machines on a network. This is what I will be covering in the second part of this HowTo.

2 - Setting up a distcc cluster

2.1 - Installation

You probably have a distcc package ready to install with your package manager, but the distcc package available at the time of writing for Debian and Raspbian provides version 3.1 of distcc.

Problem is we need a new feature introduced in version 3.2 of distcc: the ability to configure the DISTCC_IO_TIMEOUT constant that was hardcoded to 300 seconds in previous versions. If you use a previous version it's fine, but you might see this kind of error:

It means that a transfer of data has lasted more than 300 seconds, so distcc will presume the server is down, and will try to build the file locally, a thing we don't want. For example, it happened quite frequently when I was building the PCL.

So let's build distcc to have the latest version!

On both the Raspberry Pi and your PC, issue the following commands:

As usual when building a software from its sources, let's have a look to the options offered:

So if you want to be able to follow the activity of distcc in a simple GUI monitor on your Pi during the build process, you will have to install the following package:

and its dependencies (quite a few). Now we can configure, build and install distcc:

First, you have to make some symbolical links to be sure that when gcc or g++ are called on the Raspberry Pi, they are called through distcc.

So, on the Raspberry Pi run the following commands:

It's a good idea to put the export command in your ~/.bashrc file, so your PATH variable is restored when you reboot the Pi and open a new terminal. It's important to put /usr/local/bin before $PATH, because when gcc/cc/g++/c++ will be called, the system will take the first instance it will find in your PATH variable.

It's also important to set the following environment variables:

You should put these lines in your ~/.bashrc too.

Now, on your PC you have to make sure that when distcc calls your compiler, it takes your cross-compiler. To do so:

Once more, it's convenient to put the export line at the end of your ~/.bashrc file.

On your PC, you now have to run the distccd daemon:

Do these steps for each PC you want to use as a remote cross-compiler (called a server in the distcc documentation).

2.2 - Let's test it !

Let's test our distcc setup by building OpenCV !

This is what you want to see when using distributed cross-compilation: all your PC's processors working 100% while your Raspberry Pi stays calm.

After you launched the distccd daemon on each on your remote PC's ( not on the Raspberry Pi unless you want it to build OpenCV too ), issue the following commands from your Pi:

Building OpenCV took only 18 minutes for me ! Building it directly on the Raspberry Pi takes something like 5 hours ( yes, I already built it without cross distcc... And don't want to do that again to measure the exact time it takes ;) )

Note that I followed the documentation, my PC is said to have 8 processors ( 4 cores actually, with 2 threads per core )

so I allowed 8 jobs to occur in parallel in the distccd daemon. But, setting this number to twice more processors than I have:

it took 6 minutes less. This is why I suggest you to set up the distccd daemon to run (2 * Number of processors) jobs.

I hope this howto will be of some use someday to someone!

If something is not working, let me know in the comments below =)

Jeremy

3 - References

https://code.google.com/p/distcc/: the official distcc website

http://www.raspberrypi.org/phpBB3/viewtopic.php?t=11776: a Raspberry Pi Forumer using distcc to distributively build kernels on his 3-Rasperry Pi cluster.

http://raspberrypi.stackexchange.com/questions/782/how-do-i-install-distcc: see Alex Chamberlain post

http://manpages.ubuntu.com/manpages/gutsy/man1/distcc.1.html: distcc manpage on the Ubuntu Manpages ( not up to date )

http://manpages.ubuntu.com/manpages/gutsy/man1/distccd.1.html: distccd manpage on the Ubuntu Manpages

44 Comments

  1. maria says:

    Hi Jeremy,
    not so luck for me from the very first step, 'Permission denied' when i started hello_world on my raspbian :(

    Reply
    • Jeremy Nicola says:

      Hi Maria,
      I am going to check this by the end of the afternoon, and I will get back to you.

      Reply
    • zelandra says:

      Hello,

      Come on!
      Just use sudo
      or
      chmod 777 hello.cpp
      chmod 777 a.out

      Reply
  2. Garry Smith says:

    Thanks very much for your tutorial. I was able to get the compiler to generate the hello_world binary and tranferred it to my Pi. However, when I try to run it I get a segmentation fault. the File command displays the same information that you have displayed.
    I'm not sure where I should start looking for this what is causing this. I was thinking that the gcc tools were not up to date. So I started a new VM and went throught the process again and the same result.
    Could you get me to run some tests or some information that I could follow up with.
    Thanks in advance,
    Garry.

    Reply
    • Jeremy Nicola says:

      Hi Garry,
      you're welcome. I will do some tests this afternoon and I will get back to you. By the way I am not sure doing this in a VM is working, as it does not emulate the ARM instruction set of the Pi. You could do this via qemu, but I never played with it.

      Reply
    • Francesco says:

      I have the same problem. The file command on the binary gives "ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped", but I can't execute it. Is there a solution?

      Reply
  3. Maria says:

    Hi Jeremy,
    Thanks for your reply. I finally got my 'hello world' app running on my raspbian, but i've compiled it using eclipse and raspbian toolchain. Now i plan to cross compiling PCL or OpenNI, can u help me make a list of what i need to have or do to make (e.g) pcd_write running on Raspbian?

    Cheers,
    Maria

    Reply
  4. Bob Teeter says:

    Jeremy - A couple of things. 1 - Have you printed this page on a inkjet printer. Background color is dark blue-green not black and links are purple Cann't read them. Sorry I really did clean my glasses 3 times for this.
    2 - Could you put at the top of this document the enviroment for all the machines that you used. Yes you used a Raspberry Pi and and a windows box but I think that you used cygwin for the crosscompiler enviroment. Not sure but it is obvously not windows.

    Thank you for your efforts on this.

    Bob Teeter

    Reply
  5. Alec says:

    Just wanted to say thanks for writing this guide and +1 this idea. I was spending days learning about cross-compiling and getting really scared when I came across this post. I was able to get distcc set up relatively quickly and things have been pretty good since -- I got OpenCV, QT and some other libraries installed just fine. Things are still fairly slow compiling, relative to my desktop, but much faster than without distcc. I've never done cross-compiling so I can't judge relative to a working cross-compilation setup.

    Thanks again!

    Reply
    • Jeremy Nicola says:

      My pleasure, glad it was useful for you ;)

      Jeremy

      Reply
  6. Jeremy Nicola says:

    Hi Bob,
    you will find a "Download article as PDF" link on top of this page to have a black and white printable version of the Howto. As indicated at the top of the article, I am using Linux on both the remote computer and the Raspberry Pi, there is no windows box involved, just Debian, Raspbian, gcc and distcc !

    @Alec: I am happy this howto helped you! Yes, cross-compilation looks scary at first, but after practicing a little, you realize it's really easy :)

    Reply
  7. Cory says:

    This is a great find, I've been wondering if there was a tool to offload these operations. I've followed your post but ran into a problem when trying to build OpenCV (which I got from the crosstool post since the git link didn't work). I was able to build and execute hello world and I can't tell what the problem is, the snippet of output most useful is below. If you don't know what this means don't worry about it, and thank for the post.

    -- Check for working C compiler: /usr/local/bin/gcc
    -- Check for working C compiler: /usr/local/bin/gcc -- broken

    The C compiler "/usr/local/bin/gcc" is not able to compile a simple test
    program.

    It fails with the following output:

    CMakeFiles/cmTryCompileExec1518769405.dir/testCCompiler.c.o: could not read
    symbols: File in wrong format

    collect2: ld returned 1 exit status

    Reply
    • mkay says:

      I ran into the same problem. Did you find a solution for that?

      Reply
      • Jeremy Nicola says:

        Cory, Mkay,

        an other user in the comments pointed out that his distcc ended up in /usr/bin instead of /usr/local/bin as in my case.
        Maybe yours is there too and the symlinks are wrong.

        which distcc should give you the correct path.

        Jeremy

  8. Ratin Rahman says:

    While compiling ffmpeg, (or just a simple "gcc file.c -o test") I get
    "CRITICAL! distcc seems to have invoked itself recursively!"

    Reply
    • Jeremy Nicola says:

      Hi Ratin,
      if distcc exits with error code 111, make sure the path to distcc appears only once in your $PATH environment variable.

      Jeremy

      Reply
    • Ratin Rahman says:

      Ahh Found the problem, the $PATH variable contained two instances of /usr/local/bin where distcc is located:

      echo $PATH
      /usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

      eliminated the export PATH altogether and now it works

      Reply
  9. Casey Brittain says:

    I don't suppose I could get some guidance? I've followed your instructions several times (starting from clean builds on both PC and PI). Each time, I end up with this error.

    Desktop errors:

    distccd[16363] (dcc_readx) ERROR: unexpected eof fd4
    distccd[16363] (dcc_r_token_int) ERROR: read failed while waiting for token "DOTI"

    RPi errors:

    /usr/bin/make -f CMakeFiles/cmTryCompileExec1858872816.dir/build.make
    CMakeFiles/cmTryCompileExec1858872816.dir/build

    make[1]: Entering directory /home/pi/opencv/CMakeFiles/CMakeTmp'
    /usr/bin/cmake -E cmake_progress_report
    /home/pi/opencv/CMakeFiles/CMakeTmp/CMakeFiles 1

    Building CXX object
    CMakeFiles/cmTryCompileExec1858872816.dir/testCXXCompiler.cxx.o

    /usr/bin/c++ -o
    CMakeFiles/cmTryCompileExec1858872816.dir/testCXXCompiler.cxx.o -c
    /home/pi/opencv/CMakeFiles/CMakeTmp/testCXXCompiler.cxx

    distcc[2636] (dcc_build_somewhere) Warning: failed to distribute, running
    locally instead

    distcc[2637] (dcc_execvp) ERROR: failed to exec c++: No such file or
    directory

    distcc[2636] ERROR: compile
    /home/pi/opencv/CMakeFiles/CMakeTmp/testCXXCompiler.cxx on localhost failed
    with exit code 110

    make[1]: Leaving directory /home/pi/opencv/CMakeFiles/CMakeTmp'

    make[1]: ***
    [CMakeFiles/cmTryCompileExec1858872816.dir/testCXXCompiler.cxx.o] Error 110

    make: *** [cmTryCompileExec1858872816/fast] Error 2

    I'm using Ubuntu 12.04 on Desktop and latest Raspbian image.

    I've played with the sym links a lot, thinking maybe they weren't pointing where they are supposed to be (my distcc was in /usr/bin, not /usr/bin/local).

    I've also played around with the PATH variables, just to make sure it wasn't pointing to a local compiler instead of distcc.

    Any help would be amazing. This stuff's too smart for me.

    Reply
  10. Jeremy Nicola says:

    Casey,

    this part of the error message:
    distcc[2637] (dcc_execvp) ERROR: failed to exec c++: No such file or
    directory

    shows that it can not find your c++ executable.

    On the Raspberry Pi, could you run:
    which c++
    c++ --version

    and see what comes out of it?

    Reply
    • Casey Brittain says:

      Ok. I think I solved that one. My copy of Raspbian was not including libiberty, so it wasn't building distcc correctly. I pulled libiberty, then, it built fine.

      Well, I was so excited to get to the end and try building OpenCV I wasn't ready to write down the error that popped. Now, it won't give me the error again, just goes straight to trying to compile locally. I'll start clean and copy the error down.

      Reply
    • Thomas Brittain says:

      So, I'm still tinkering. I did try which c++, it gave:

      /usr/local/bin

      When I gave it c++ --version, it gave me:

      distcc[2331] (main) CRITICAL! distcc seems to have invoked itself recursively!
      distcc[2330] ERROR: compile (null) on localhost failed with exit code 111

      Out of respect of the other comments, I brought my PATH variable down to -just- /usr/local/bin and I was still getting the recursively error.

      Reply
      • Jeremy Nicola says:

        Thomas,

        "which c++" should return something like:
        /usr/local/bin/c++ and not a directory, /usr/local/bin/ in your case.

        Please re-check you made the symbolic links right.

  11. Casey Brittain says:

    So, I've about given up. Followed the instructions from the ground up several more times with no success. I don't suppose someone could look over my build and tell me where I'm going wrong? I'm ok being looking dumb if I get it right in the end.

    http://cthomasbrittain.wordpress.com/2013/06/12/distcc-and-rpi/

    I continue to end with either the 111 error, or the can't find c++ error. Some variants I can get it to connect to the desktop, others I can't.

    Reply
  12. juanmol says:

    Hi, maybe you can help me. I'm trying to use distcc to compile asterisk for my raspberrypi, i've follow all steps. In pc:
    # distccd --daemon --jobs 8 --allow 192.168.1.2 --verbose --log-stderr --no-detach
    distccd[28296] (dcc_preferred_user) Warning: no such user as "distcc"
    distccd[28296] (dcc_discard_root) discarded root privileges, changed to uid=65534 gid=65534
    distccd[28296] (main) chdir to /tmp
    distccd[28296] (dcc_setup_daemon_path) daemon's PATH is /usr/src/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
    distccd[28296] (dcc_listen_by_addr) listening on 0.0.0.0:3632
    distccd[28296] (dcc_defer_accept) TCP_DEFER_ACCEPT turned on
    distccd[28296] (dcc_standalone_server) 8 CPUs online on this server
    distccd[28296] (dcc_standalone_server) allowing up to 8 active jobs
    distccd[28296] (dcc_standalone_server) not detaching
    distccd[28296] (dcc_new_pgrp) already a process group leader
    distccd[28296] (dcc_log_daemon_started) preforking daemon started (3.2rc1 x86_64-unknown-linux-gnu, built Jul 15 2013 07:50:36)
    distccd[28296] (dcc_create_kids) up to 1 children
    distccd[28296] (dcc_create_kids) up to 2 children
    distccd[28296] (dcc_create_kids) up to 3 children
    distccd[28296] (dcc_create_kids) up to 4 children
    distccd[28296] (dcc_create_kids) up to 5 children
    distccd[28296] (dcc_create_kids) up to 6 children
    distccd[28296] (dcc_create_kids) up to 7 children
    distccd[28296] (dcc_create_kids) up to 8 children

    in the Raspberrypi:
    asterisk-11.4.0# make
    CC="cc" CXX="" LD="" AR="" RANLIB="" CFLAGS="" LDFLAGS="" make -C menuselect CONFIGURE_SILENT="--silent" makeopts
    make[1]: Entering directory /usr/src/asterisk/asterisk-11.4.0/menuselect'
    make[1]:
    makeopts' is up to date.
    make[1]: Leaving directory /usr/src/asterisk/asterisk-11.4.0/menuselect'
    CC="cc" CXX="" LD="" AR="" RANLIB="" CFLAGS="" LDFLAGS="" make -C menuselect CONFIGURE_SILENT="--silent" menuselect
    make[1]: Entering directory
    /usr/src/asterisk/asterisk-11.4.0/menuselect'
    make[1]: menuselect' is up to date.
    make[1]: Leaving directory
    /usr/src/asterisk/asterisk-11.4.0/menuselect'
    [CC] hash/hash_buf.c -> hash/hash_buf.o
    distcc[22357] ERROR: compile hash/hash_buf.c on 192.168.1.54/8 failed with exit code 127
    gcc: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
    make[2]: *** [hash/hash_buf.o] Error 127
    make[1]: *** [db1-ast/libdb1.a] Error 2
    make: *** [utils] Error 2

    in pc:
    # dpkg -l | grep libstdc++
    ii libstdc++6:amd64 4.7.3-1ubuntu1 amd64 GNU Standard C++ Library v3
    ii libstdc++6-4.7-dev:amd64 4.7.3-1ubuntu1 amd64 GNU Standard C++ Library v3 (development files)

    in Raspberrypi:
    # dpkg -l | grep libstdc++
    ii libstdc++6:armhf 4.7.1-2+rpi1 GNU Standard C++ Library v3
    ii libstdc++6-4.6-dev 4.6.3-8+rpi1 GNU Standard C++ Library v3 (development files)

    how i can fix it?

    Reply
    • juanmol says:

      if i run make without activate the listener in the pc, have no problems.

      Reply
      • juanmol says:

        me again, sorry for the insistence. I've solve it by updating gcc in the raspberrypi, but now i have other problem:

        at pc:
        distccd --daemon --jobs 8 --allow 192.168.1.2 --verbose --log-stderr --no-detach
        (...)
        distccd[28380] (dcc_create_kids) up to 8 children

        at raspberrypi:
        make
        CC="cc" CXX="" LD="" AR="" RANLIB="" CFLAGS="" LDFLAGS="" make -C menuselect CONFIGURE_SILENT="--silent" makeopts
        make[1]: Entering directory /usr/src/asterisk/asterisk-11.4.0/menuselect'
        make[1]:
        makeopts' is up to date.
        make[1]: Leaving directory /usr/src/asterisk/asterisk-11.4.0/menuselect'
        CC="cc" CXX="" LD="" AR="" RANLIB="" CFLAGS="" LDFLAGS="" make -C menuselect CONFIGURE_SILENT="--silent" menuselect
        make[1]: Entering directory
        /usr/src/asterisk/asterisk-11.4.0/menuselect'
        gcc -g -D_GNU_SOURCE -Wall -c -o menuselect.o menuselect.c
        distcc[363] (main) CRITICAL! distcc seems to have invoked itself recursively!
        distcc[361] ERROR: compile (null) on localhost failed with exit code 111
        distcc[360] ERROR: compile menuselect.c on 192.168.1.54/8 failed with exit code 111
        make[1]: *** [menuselect.o] Error 111
        make[1]: Leaving directory `/usr/src/asterisk/asterisk-11.4.0/menuselect'
        make: *** [menuselect/menuselect] Error 2

        recursively???? In pc i see:

        distccd[28381] (dcc_input_tmpnam) input file menuselect.c
        distccd[28381] (dcc_readx) ERROR: unexpected eof on fd4
        distccd[28381] (dcc_r_token_int) ERROR: read failed while waiting for token "DOTI"
        distccd[28381] (dcc_cleanup_tempfiles_inner) deleted 5 temporary files
        distccd[28381] (dcc_job_summary) client: 192.168.1.2:47342 OTHER exit:0 sig:0 core:0 ret:108 time:2ms

    • juanmol says:

      sorry again, i've fix most of errors, by rechecking the PATH in both systems. Now i can compile a lot, but when i run "make menuselect":
      (...)
      gcc -o cmenuselect menuselect.o strcompat.o menuselect_curses.o mxml/libmxml.a -lncurses
      menuselect.o: file not recognized: File format not recognized

      if i do:
      file ./menuselect/menuselect.o
      ./menuselect/menuselect.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
      is bad system, true? If i turn off distcc on pc, and "make menuselect" again in the raspberry, doesn't fail and:
      file ./menuselect/menuselect.o
      ./menuselect/menuselect.o: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped
      is correct. How i can fix it?

      Reply
      • Jeremy Nicola says:

        Juanmol,

        from the previous errors it seems you had at least 2 occurrences of the distcc installation directory in your PATH env. variable.

        For the new error, yes it should say that menuselect.o is an ELF 32-bit LSB file.
        Please check again that when gcc is called on your PC, it actually calls the GCC of your ARM tool-chain.

  13. wael says:

    Hi Jeremy..
    i was installing the distcc by the command "sudo make install". unfortunately, I got this error:

    src/distcc.c:44:23: fatal error: libiberty.h: No such file or directory
    compilation terminated.
    make: *** [src/distcc.o] Error 1

    Any help please!

    Reply
    • Jeremy Nicola says:

      Run:

      sudo apt-get install binutils

      and see if the error is still thrown.

      Jeremy

      Reply
      • Adrian says:

        You need sudo apt-get install binutils-dev

  14. Himbeere says:

    First: Thanks for your great tutorial!! However, I still have one question left concerning this part:

    "But now imagine you want to cross-compile a library that depends on other librairies (which, in turn, could depend on other libraries...). How will you do to satisfy these dependencies? Having the libraries installed on your PC won't work, because they are compiled to run on a non-ARM architecture ( probably x86 x86_64 )."

    How can this step included in distcc? E.g. i want to use boost with raspbian and distcc?

    Reply
  15. Matt says:

    I'm so close, but one thing seems to be wrong somewhere....

    gcc runs find, but during linking I get the following every time:

    /usr/bin/ld: .libs/aacenc.o: Relocations in generic ELF (EM: 3)
    /usr/bin/ld: .libs/aacenc.o: Relocations in generic ELF (EM: 3)
    /usr/bin/ld: .libs/aacenc.o: Relocations in generic ELF (EM: 3)
    /usr/bin/ld: .libs/aacenc.o: Relocations in generic ELF (EM: 3)
    /usr/bin/ld: .libs/aacenc.o: Relocations in generic ELF (EM: 3)
    .libs/aacenc.o: could not read symbols: File in wrong format
    collect2: ld returned 1 exit status

    Any ideas?

    I'm trying with libaacplus here, but the problem occurs any time I link anything with distcc.

    Reply
  16. Daniel says:

    Hi Jereme,

    Great Tutorial!, I was just wondering. Is it possible to start the cross-compiling from the PC instead of having to use the distcc?

    Thanks

    Reply
  17. Panca says:

    Hi,

    Thanks for this. To get this working on Ubuntu 13.10 I had to install the following additional packages (not sure if really all of them are required, but these are enough ;)). Without them I get a /path/to/arm/gcc not found error if I execute gc (while 'which gcc' gives the expected result):

    ibc6-i386
    lib32bz2-1.0
    lib32z1
    lib32stdc++6
    lib32ncurses5

    To build distcc successfully, another package is required:

    binutils-dev (for libiberty)

    And you have to use --disable-Werror on configure

    Best
    -p-

    Reply
  18. Mehow says:

    Great guide. I've been struggling with getting with this issue for a few days now and couldn't find any good guide for it. Thumbs up!

    Reply
  19. Marco says:

    Hi Nicole,

    great guide, outstanding job.
    I'm having quite a problem trying to execute de MAKE on the PI. Apparently, it's not connecting to my PC host.
    I did set already the DISTCC_HOST address on my pi (my pc's ip)
    Also, when starting the deamon on my PC I input correctly the IP address of my PI.

    The error I get from the PI is the following:

    distcc[27875] ERROR: nonblocking connect to 127.0.0.1/3632 failed.

    Now, checking distcc --show-hosts, I see that distcc has the right IP path/address (MY PC).
    Could you please provide some orientation of what could possible is blocking connection between PI and PC when attepting to compilate opencv??

    Thanx!

    Reply
  20. Marco says:

    Just, FYI, I called you Nicole by error! Sorry Jeremy!!!!! I misread your first name.

    Regards,

    Marco.

    Reply
  21. Kuta says:

    Hi,
    I tried to build the pcl with the help of your tutorial, but somehow I didn't get a distcc connection between desktop and raspberry. I was able to build the simple hello world program and let it run on the rasp, but when I launch my distccd he creates the children, but nothing happens.

    distccd[12383] (dcc_preferred_user) Warning: no such user as "distcc"
    distccd[12383] (dcc_discard_root) discarded root privileges, changed to uid=65534 gid=65534
    distccd[12383] (main) chdir to /tmp
    distccd[12383] (dcc_setup_daemon_path) daemon's PATH is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    distccd[12383] (dcc_listen_by_addr) listening on 0.0.0.0:3632
    distccd[12383] (dcc_defer_accept) TCP_DEFER_ACCEPT turned on
    distccd[12383] (dcc_standalone_server) 2 CPUs online on this server
    distccd[12383] (dcc_standalone_server) allowing up to 4 active jobs
    distccd[12383] (dcc_standalone_server) not detaching
    distccd[12383] (dcc_new_pgrp) entered process group
    distccd[12383] (dcc_log_daemon_started) preforking daemon started (3.2rc1 x86_64-unknown-linux-gnu, built Feb 25 2014 08:50:52)
    distccd[12383] (dcc_create_kids) up to 1 children
    distccd[12383] (dcc_create_kids) up to 2 children
    distccd[12383] (dcc_create_kids) up to 3 children
    distccd[12383] (dcc_create_kids) up to 4 children

    I installed also everything on the rasp and added the exports to the bashrc, but he still compilles on the rasp. Is there a possibility to check if distccd is running or connecting right?

    Greetings

    Reply
  22. Bob says:

    Hi Jeremy,

    Thanks. Nice tutorial. Everything went well. Just one little hitch. As I use Cython in my builds /usr/local/bin was already in my $PATH which I didn't notice so when I ran I was getting an error 'recursive call to distcc'. I just moved the links to /usr/local/bin/links and all was fine.

    Bob

    Reply
  23. Bob says:

    Jeremy,
    One thing I have noticed is that files that are up to date are still rebuilt. There are 3 machines involved, Win7 that holds all files. Pi that mounts the Win7 share and a Mint build VM running on the Win7 box. The clocks are not synced but I didn't think that mattered. Any ideas?

    Bob

    Reply
  24. Manuel says:

    Thanks for the nice Tutorial.
    I ran in some issues when trying to setup the official toolchain.
    Just because i used the stable version of Debian with an older version of libc. But after upgrading to the testing branch of Debian it worked great.

    What you could add to your tutorial is an export of the PATH in the bashrc file like it's mentioned on StackOverflow: http://stackoverflow.com/questions/19162072/installing-raspberry-pi-cross-compiler

    Reply

Leave a Comment

  • @JeremyNicola

    Follow