I've got Jade set up and running fine on Arch Linux Arm on a raspberry pi.

In the interest of expediting compilation of ros packages on the raspberry pi, I'm attempting to configure distcc for use in a catkin workspace. I found the catkin_tools package on github (and in the aur) and installed. However, when I execute

CC="distcc gcc" CXX="distcc g++" catkin build -p$(distcc -j) -j$(distcc -j) --no-jobserver

from to the catkin_tools documentation, the process apparently spins its wheels until the pi runs out of memory. Output:

[user@alarmpi catkin_workspace]$ CC="distcc gcc" CXX="distcc g++" catkin build -p$(distcc -j) -j$(distcc -j) --no-jobserver                      
---------------------------------------------------------------
Profile:                     default
Extending:          [cached] /opt/ros/jade
Workspace:                   /home/user/catkin_workspace
Source Space:       [exists] /home/user/catkin_workspace/src
Build Space:        [exists] /home/user/catkin_workspace/build
Devel Space:        [exists] /home/user/catkin_workspace/devel
Install Space:     [missing] /home/user/catkin_workspace/install
DESTDIR:                     None
---------------------------------------------------------------
Isolate Develspaces:         False
Install Packages:            False
Isolate Installs:            False
---------------------------------------------------------------
Additional CMake Args:       None
Additional Make Args:        -j4
Additional catkin Make Args: None
Internal Make Job Server:    False
---------------------------------------------------------------
Whitelisted Packages:        None
Blacklisted Packages:        None
---------------------------------------------------------------
Workspace configuration appears valid.
--------------------------------------------------------------- 
Found '2' packages in 0.3 seconds. 
Starting ==> robot_motion                                               
Starting ==> joy                                                        
[build] Runtime: 3 minutes and 19.7 seconds joy - 03:18.2]
Traceback (most recent call last):
  File "/usr/bin/catkin", line 9, in <module>
    load_entry_point('catkin-tools==0.3.1', 'console_scripts', 'catkin')()
  File "/usr/lib/python2.7/site-packages/catkin_tools/commands/catkin.py", line 229, in main
    sys.exit(args.main(args) or 0)
  File "/usr/lib/python2.7/site-packages/catkin_tools/verbs/catkin_build/cli.py", line 334, in main
    summarize_build=opts.summarize  # Can be True, False, or None
  File "/usr/lib/python2.7/site-packages/catkin_tools/verbs/catkin_build/build.py", line 828, in build_isolated_workspace
    wide_log(msg, rhs=msg_rhs, end='\r')
  File "/usr/lib/python2.7/site-packages/catkin_tools/common.py", line 430, in wide_log
    wide_log_fn(msg, **kwargs)
  File "/usr/lib/python2.7/site-packages/catkin_tools/common.py", line 366, in __wide_log
    width = terminal_width()
  File "/usr/lib/python2.7/site-packages/catkin_tools/common.py", line 288, in terminal_width
    return terminal_width_windows() if os.name == 'nt' else terminal_width_linux()
  File "/usr/lib/python2.7/site-packages/catkin_tools/common.py", line 280, in terminal_width_linux
    width = os.popen('tput cols', 'r').readline()
OSError: [Errno 12] Cannot allocate memory

I'm under the impression I've set up distcc correctly because when I went through guides on configuring makepkg to use distcc, and compile times dropped drastically with yaourt, and distccmon-text shows the compile processes on my external machine. By contrast, no processes show up with distccmon-text when running the above command. The two packages I'm trying to compile do finish the compilation process without the distcc switches, just in a painful amount of time.

My external machine has 4 cores, and my intention was to offload all compilation (besides the processing, for now) to it. distcc -j spits out 4.

Any help would be greatly appreciated -- thank you.

Edit: moved output to post rather then pastebin.

EDIT: Figured out that I forgot to set the DISTCC_HOSTS environment variable. This solved the apparent memory leak issue, however it still doesn't appear that the compile process is using distcc, based on the lack of output from distccmon-text and compile times.