Csl /Daily

Edit this page (without having to scroll to the bottom). :)

On this page... (hide)

2008

June

Et al. in Latex/bibtex

Ever wonder how to get et al. to show up in your bibliography entry? Turns out you just make the list something like: 

 @ARTICLE{ j:ref-info-2008,
   author={Sprinkle and others},
   ...
 }

and BibTeX sorts out the rest.

March

"The disk is full or too many files are open" Error Message in Microsoft Word

See http://www.dessci.com/en/support/mathtype/tsn/TSN64.htm

Using Ice in/out of a firewall run by iptables

I was having trouble using Ice on my machine, bracton.ece, since bracton has two network cards, and (evidently) only machines inside the lab were able to use Ice.

I tested for connectivity using the Orca utility, iceping 

 dimble@dimble:~$ iceping -r
 Ice version: 3.2.0
 assumed config file: --Ice.Config=/home/dimble/.orcarc
 03/04/08 13:43:06.216 warning: unknown property: Ice.Timeout

 Ping failed.
 Network.cpp:622: Ice::ConnectTimeoutException:
 timeout while establishing a connection

This machine, dimble.ece, has a live internet address (150.135.217.180). However, running iceping on a machine with an internal lab address is successful. 

 maggs@maggs:~$ iceping -r
 Ice version: 3.2.0
 assumed config file: --Ice.Config=/home/maggs/.orcarc
 03/04/08 13:48:08.983 warning: unknown property: Ice.Timeout

 Ping successful.
 Proxy		[ IceGrid/Query -t ]
 Connection	[ local address = 192.168.1.6:45136
 remote address = 150.135.217.192:12000 ]
 RTT (3) 	[ 1500 us ]
 Ice ID 		[ ::IceGrid::Query ]

Note that it believes that bracton's ip is the internet (not subnet) version. I also tested on bracton: 

 sprinkjm@bracton:/etc/sysconfig$ /opt/orca-dgc/bin/iceping -r
 Ice version: 3.2.1
 assumed config file: --Ice.Config=/home/sprinkjm/.orcarc
 03/04/08 13:42:20.103 warning: unknown property: Ice.Timeout

 Ping successful.
 Proxy		[ IceGrid/Query -t ]
 Connection	[ local address = 150.135.217.192:49557
 remote address = 150.135.217.192:12000 ]
 RTT (3) 	[ 3229 us ]
 Ice ID 		[ ::IceGrid::Query ]

OK, so clearly the problem is that there is a firewall issue. The only question was: is this blocked by the department routers, or is it bracton's firewall holding us back? Since I only had access to the firewall on bracton, I changed it to see. ;)

/etc/sysconfig/iptables
...
# entries for Orca/Ice
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 12000 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 12000 -j ACCEPT

#-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
#-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-P INPUT DROP
COMMIT
[Get Code]

After adding these entries, I restarted iptables 

 sudo /etc/init.d/iptables stop
 sudo /etc/init.d/iptables stop
 sudo /etc/init.d/iptables start

I run stop twice, rather than restart, since some of the modules take more time to come down than iptables actually likes. Now that iptables is back up, we test using dimble (the machine with the 'live' IP) 

 dimble@dimble:~$ iceping -r
 Ice version: 3.2.0
 assumed config file: --Ice.Config=/home/dimble/.orcarc
 03/04/08 13:49:23.506 warning: unknown property: Ice.Timeout

 Ping successful.
 Proxy		[ IceGrid/Query -t ]
 Connection	[ local address = 150.135.217.180:38917
 remote address = 150.135.217.192:12000 ]
 RTT (3) 	[ 16112 us ]
 Ice ID 		[ ::IceGrid::Query ]

Success! I thought....If I VPN into campus, I can (theoretically) get access to the icegridregistry running on bracton. However, this didn't actually pan out.

Running simple components, such as laser2d fail to connect and stream data. That is, a connection ocurrs, but the data doesn't keep coming. I think this is related to the use of Proxies, so I will see what else I can do. I hope that I don't have to create a separate NAT entry for each machine to forward proxy ports...that would not be cool.

February

Using Slice files with Doxygen

I am using Orca, which has a built-in doxygen script for satellite projects. However, the existing Sourceforge documentation is generated using a patched version of the Doxygen executable.

After poking around, I discovered this entry in a ZeroC forum. To implement this for an Orcasatellite project, the following needs to be created. Create slice.sed in the doc/ directory of the Orca satellite project.

slice.sed
# Skip C-style commenting
/\/\*/ , /\*\//b
/\/\/\(.*\)/b

s/module/namespace/
s/local//
s/idempotent//
s/dictionary/map/
s/sequence/vector/

#parse local interface
/interface/ , /{/    {
    /interface/ {
        #change interface to class
        s/interface\(.*\)/class \1/
    }
#change extends
    s/extends/: public/
#add public before every keyword, but not {
    /{/!s/,\(.*\)/, public \1/g
    s/{/{public:/
}

s/nonmutating\(.*)\)/\1 const/

/throws/,/;/ {
    s/throws/throw(/
    s/;/);/
}
[Get Code]
slice2doxy
#!/bin/sh
sed -f slice.sed $1
[Get Code]

Mark this slice2doxy file as user executable (make sure you do this before committing it to SVN/CVS). :) 

 chmod u+x slice2doxy

With these files in play, edit the Doxyfile to have the following values:

project.Doxyfile
FILTER_PATTERNS = *.ice=./slice2doxy
[Get Code]

Note that without the ./ before slice2doxy that the script may not work (it didn't work on my Kubuntu machine since the current director is not in the path...).

This solution is slightly more elegant than the one on ZeroC's site (though I heavily acknowledge the sed script from there!!!) since we now only pass through *.ice files, and not every file we parse.

Allowing SSH into Mac OS X

You only need to enable "remote login" using the System Preferences box. 

 System Preferences->Sharing->Remote Login

I also added my machine to the dnsmasq.conf entry, so I would always get the same IP address.

Running IceGridRegistry on Fedora Core 8 as a daemon

Here's a howto for running icegridregistry as a daemon on FC8. I got a lot of this information from the DGC3 wiki, leftover from when I figured this out last time... :( 

 cd /usr/local/sbin
 sudo mkdir -p icereg
 sudo cp /usr/local/src/[orca2]/scripts/ice/icegridregistry.cfg icereg/
 cd icereg/
 sudo mkdir db

Now, we create a few files

/etc/default/icegridregistry
# Customize the variables in /etc/default/icegridregistry rather than here
# uncomment based on whichever you prefer
#ICECHDIR=
ICECHDIR="--chdir /usr/local/sbin/icereg"

ICECONFIG="--Ice.Config=/usr/local/sbin/icereg/icegridregistry.cfg"
[Get Code]

The existing file I had for icegridregistry was for ubuntu:

/etc/init.d/icegridregistry-ubuntu
#!/bin/sh
#
# /etc/init.d/icegridregistry   Start icegridregistry daemon.
#
#

# Customize the variables in /etc/default/icegridregistry rather than here

set -e

. /lib/lsb/init-functions


BINNAME=icegridregistry
CONFIGNAME=$BINNAME
ICECONFIG=""
ICECHDIR=""

[ -f /etc/default/$CONFIGNAME ] && . /etc/default/$CONFIGNAME

NET="$ICE_HOME/bin"
test -f ${NET}/${BINNAME} | exit 0

# Method to start up the daemon
do_start ()
{
        log_begin_msg "Starting ${CONFIGNAME}:"
        start-stop-daemon --start --quiet \
                ${ICECHDIR} \
                --exec ${NET}/${BINNAME} -- $ICECONFIG --daemon --nochdir
        log_end_msg 0
}

do_stop () {
        log_begin_msg "Stopping ${CONFIGNAME}:"
        start-stop-daemon --stop --quiet --oknodo --exec ${NET}/${BINNAME}
#       DAEMONPID=$(cat $PIDFILE | tr -d '[:blank:]')
#       KILLCOUNT=1
#       while [ $KILLCOUNT -le 5 ]; do
#               if stillrunning; then
#                       kill $DAEMONPID
#               else
#                       break
#               fi
#               sleep 1
#               KILLCOUNT=$(( $KILLCOUNT + 1 ))
#       done
#       if stillrunning; then
#               echo -n " not responding to TERM signal (pid $DAEMONPID)"
#       fi
        log_end_msg 0
}

# Set 'manual' to indicate if we were started by hand.
case "$0" in
        */S[0-9][0-9]*|*/K[0-9][0-9]*)
                manual=
                ;;
        *)
                manual=1
                ;;
esac

case "$1" in
  start)
        do_start
        ;;
  stop)
        do_stop
        ;;
  restart)
        do_stop
        sleep 2
        do_start
        ;;
  *)
        log_success_msg "Usage: /etc/init.d/${BINNAME} {start|stop|restart}"
        exit 1
esac

exit 0

 
[Get Code]

I made a copy of the httpd start/stop, and hacked it for icegridregistry

/etc/init.d/icegridregistry
#!/bin/bash
# Author: Jonathan Sprinkle
#
# icegridregistry       Startup script for the Ice grid registry
#
# chkconfig: - 85 15
# description: The icegridregistry maintains a list of platforms with
#              available middleware services/interfaces provided.
# processname: icegridregistry
# config: /etc/default/icegridregistry
# pidfile: /var/run/icegridregistry.pid
#
### BEGIN INIT INFO
# Provides: icegridregistry
# Required-Start: $local_fs $remote_fs $network $named
# Required-Stop: $local_fs $remote_fs $network
# Should-Start:
# Short-Description: start and stop IceGridRegistry daemon
# Description: The icegridregistry maintains a list of platforms with
#  available middleware services/interfaces provided.
### END INIT INFO

# Source function library.
. /etc/rc.d/init.d/functions

if [ -f /etc/default/icegridregistry ]; then
        . /etc/default/icegridregistry
fi

# Path to the apachectl script, server binary, and short-form for messages.
#apachectl=/usr/sbin/apachectl
#httpd=${HTTPD-/usr/sbin/httpd}
icegridregistry=/usr/bin/icegridregistry
prog=icegridregistry
pidfile=${PIDFILE-/var/run/icegridregistry.pid}
lockfile=${LOCKFILE-/var/lock/subsys/icegridregistry}
RETVAL=0

# So we just do it the way init scripts
# are expected to behave here.
start() {
        echo -n $"Starting $prog: "
        $icegridregistry --pidfile ${pidfile} $ICECONFIG --daemon --nochdir
        #$icegridregistry --pidfile ${pidfile} --$ICECONFIG --daemon --nochdir
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && touch ${lockfile}
        return $RETVAL
}

# When stopping icegridregistry, we give a delay of >10 second before SIGKILLing the
# icegridregistry parent; this gives enough time for the parent to SIGKILL any
# errant children.
# (maybe over the top, but we have plenty of time...)
stop() {
        echo -n $"Stopping $prog: "
        killproc -p ${pidfile} -d 10 $icegridregistry
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && rm -f ${lockfile} ${pidfile}
}

# See how we were called.
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  status)
        status $httpd
        RETVAL=$?
        ;;
  restart)
        stop
        start
        ;;
  condrestart)
        if [ -f ${pidfile} ] ; then
                stop
                start
        fi
        ;;
  *)
        echo $"Usage: $prog {start|stop|restart|condrestart|status}"
        RETVAL=3
esac

exit $RETVAL
 
[Get Code]

To start: 

 sudo /etc/init.d/icegridregistry start

Things *should* run fine. To check that it is running: 

 /bin/ps aux | grep icegrid

Now things look good. One last thing to do is add icegridregistry to the default runlevel for each of the 3,4,5 runlevels. I'm working on this...in the meantime, I have to ensure every time bracton restarts (once a semester?) I remember to restart the registry.

To ping something on ice, just to be super sure, you can use the iceping utiltity, which is an Orca product: 

 sprinkjm@bracton:/usr/local/sbin/icereg$ /opt/orca-dgc/bin/iceping -r
 Ice version: 3.2.1
 assumed config file: --Ice.Config=/home/sprinkjm/.orcarc
 02/20/08 12:49:44.705 warning: unknown property: Ice.Timeout 

 Ping successful.
 Proxy		[ IceGrid/Query -t ]
 Connection	[ local address = 150.135.217.192:58282
 remote address = 150.135.217.192:12000 ]
 RTT (3) 	[ 9036 us ]
 Ice ID 		[ ::IceGrid::Query ]

Note that this assumes you have a ~/.orcarc file, since Orca 'houses' iceping. Here is a good one to use:

~/.orcarc
# Ice configuration

# Uncomment for being connected to bracton/UA campus
Ice.Default.Locator=IceGrid/Locator:default -h bracton.ece.arizona.edu -p 12000# IceStorm.TopicManager.Proxy=IceStorm/TopicManager:default -h bracton.ece.arizona.edu -p 10000

# Uncomment for using localhost
# Ice.Default.Locator=IceGrid/Locator:default -p 12000
# IceStorm.TopicManager.Proxy=IceStorm/TopicManager:default -p 10000

 Ice.Override.ConnectTimeout=1000
 Ice.Timeout=200

# Orca config
Orca.PrintProperties=0
Orca.PrintComponentStarted=0
Orca.RequireRegisty=1

# Orca Tracer config
Orca.Tracer.RequireIceStorm=0
Orca.Tracer.Filename=orca_component_trace.txt
Orca.Tracer.InfoToDisplay=1
Orca.Tracer.InfoToNetwork=0
Orca.Tracer.InfoToLog=0
Orca.Tracer.InfoToFile=0
Orca.Tracer.WarningToDisplay=1
Orca.Tracer.WarningToNetwork=0
Orca.Tracer.WarningToLog=0
Orca.Tracer.WarningToFile=0
Orca.Tracer.ErrorToDisplay=10
Orca.Tracer.ErrorToNetwork=0
Orca.Tracer.ErrorToLog=0
Orca.Tracer.ErrorToFile=0
Orca.Tracer.DebugToDisplay=0
Orca.Tracer.DebugToNetwork=0
Orca.Tracer.DebugToLog=0
Orca.Tracer.DebugToFile=0
Orca.Tracer.IgnoreRepeatedWarnings=1
Orca.Tracer.IgnoreRepeatedErrors=1
Orca.Tracer.Timestamp=1
 
[Get Code]

Installing Orca on Fedora Core 8

I began at http://orca-robotics.sourceforge.net/orca/orca_doc_installfedora.html 

 sprinkjm@bracton:~$ sudo yum install db4
 Setting up Install Process
 Parsing package install arguments
 Package db4 - 4.6.21-1.fc8.i386 is already installed.
 Nothing to do
 sprinkjm@bracton:~$ sudo yum install expat
 Setting up Install Process
 Parsing package install arguments
 Package expat - 2.0.1-2.i386 is already installed.
 Nothing to do
 sprinkjm@bracton:~$ sudo yum install openssl
 Setting up Install Process
 Parsing package install arguments
 Package openssl - 0.9.8b-17.fc8.i686 is already installed.
 Nothing to do

Hm, it seems like most of my packages were already installed by Marti (yay, Marti!) in his FC8 image. I'll check the rest en masse: 

 sprinkjm@bracton:~$ sudo yum install bzip2-libs readline ncurses libgcc libstdc++ openssl-devel db4-utils doxygen
 Setting up Install Process
 Parsing package install arguments
 Package bzip2-libs - 1.0.4-12.fc8.i386 is already installed.
 Package readline - 5.2-7.fc8.i386 is already installed.
 Package ncurses - 5.6-12.20070812.fc8.i386 is already installed.
 Package libgcc - 4.1.2-33.i386 is already installed.
 Package libstdc++ - 4.1.2-33.i386 is already installed.
 Package openssl-devel - 0.9.8b-17.fc8.i386 is already installed.
 Package doxygen - 1:1.5.4-1.fc8.i386 is already installed.

After this, db4-utils (4.6.21-1) and readline (5.2-10) were installed. Next to install was CMake, but I had already installed it (v.2.4.7).

I was hoping that ICE would exist as a Fedora package... 

 sudo yum search libzeroc-ice
 No Matches Found

Shucks. However, I looked on the ZeroC site, and they do have a binary version, but you have to edit the yum sources. 

 cd /etc/yum.repos.d/
 wget http://www.zeroc.com/download/Ice/3.2/rhel4/zeroc-ice.repo

Now, I can check for it again with yum: 

 sudo yum update

You should see at the top that it gets the new ice repositories. 

 zeroc-ice                 100% |=========================|  951 B    00:00     
 primary.xml.gz            100% |=========================| 5.8 kB    00:00     
 zeroc-ice : ################################################## 32/32
 Setting up Update Process
 Resolving Dependencies

I said "N" at the end when it asked me to update packages (I find upgrading never goes as planned on an enterprise machine...). So, to install, I checked what ice was in the repository 

 sudo yum search zeroc

And found that ice and ice-devel both existed, along with lots of other stuff. So, I installed ice-devel, figuring that ice will be installed too. 

 sprinkjm@bracton:~$ sudo yum install ice-devel
 Setting up Install Process
 Parsing package install arguments
 Resolving Dependencies
 --> Running transaction check
 ---> Package ice-devel.i386 0:3.2.1-13.fc8 set to be updated
 --> Processing Dependency: libIceGrid.so.32 for package: ice-devel
 --> Processing Dependency: ice = 3.2.1-13.fc8 for package: ice-devel
 --> Processing Dependency: libIcePatch2.so.32 for package: ice-devel
 --> Processing Dependency: libIceSSL.so.32 for package: ice-devel
 --> Processing Dependency: libIce.so.32 for package: ice-devel
 --> Processing Dependency: libFreeze.so.32 for package: ice-devel
 --> Processing Dependency: libGlacier2.so.32 for package: ice-devel
 --> Processing Dependency: libIceStormService.so.32 for package: ice-devel
 --> Processing Dependency: libSlice.so.32 for package: ice-devel
 --> Processing Dependency: libIceUtil.so.32 for package: ice-devel
 --> Processing Dependency: libIceStorm.so.32 for package: ice-devel
 --> Processing Dependency: libIceBox.so.32 for package: ice-devel
 --> Running transaction check
 ---> Package ice.i386 0:3.2.1-13.fc8 set to be updated
 --> Finished Dependency Resolution

Golden. Now, Ice is installed, let's move on to the other dependencies of Orca. 

 sudo yum install qt4-x11

Next...it's time to install orca. Before I set the paths and everything, I wanted to see whether it was possible to build Orca without hacking the /etc/profile: 

 cd /usr/local/src/
 wget http://www.ece.arizona.edu/~sprinkjm/teaching/ece473/uploads/Main/orca2-ece473-573.tgz 
 tar xzf orca2-ece473-573.tgz && cd orca2-ece473-573 && mkdir build && cd build
 cmake .. && make -j2 && sudo make install

It found everything ok, without setting special paths: 

 --Setting ICE_HOME to /usr
 -- This is a Debian Ice installation. Slice files are in /usr/share
 -- Looking for Ice - found in /usr
 -- Looking for C++ include Ice/Ice.h
 -- Looking for C++ include Ice/Ice.h - found
 -- Checking Ice version - 3.2.1 - ok

However, the build failed because it couldn't find the .ice files 

 [  3%] -- Generating header file from  /usr/local/src/orca2-ece473-573/src/interfaces/slice/orca/home.ice
 /usr/local/src/orca2-ece473-573/src/interfaces/slice/orca/home.ice:15:   Ice/BuiltinSequences.ice: No such file or directory
 make[2]: *** [src/interfaces/cpp/orca/home.h] Error 1
 make[1]: *** [src/interfaces/cpp/orca/CMakeFiles/OrcaInterfaces.dir/all] Error 2
 make[1]: *** Waiting for unfinished jobs....

But, that file is in /usr/share/Ice-3.2.1/slice/Ice. So, ccmake to the rescue! I set the Orca Slice Files location to /usr/share/Ice-3.2.1, and the build took off!!

Installing usb networking on Mac OS X for gumstix

I basically did what Dave Hylands did on the gumstix webpage:

http://docwiki.gumstix.org/Setting_up_USBnet

It turns out that using this can wreak havoc on vmware. I had to remove the en2 ethernet to boot to my VMWare images, even after a few reboots. More updates to come, if I solve it...

Orca installation on fresh install of Gutsy Gibbon

I know that chasing the head of the development tree can make for rocky stability, so I decided I'd go with the latest release rather than the trunk for both orca and hydro. Since I love creating scripts to do installs on multiple machines, I investigated using svn as the checkout method, to avoid having to sit in front of the machine and wait for sourceforge to produce a mirror for me to download from.

I noticed that there's no tag for Orca for release 2.9.0. A release exists (as I saw on the orca-robotics website).

So, I just checked out the same revision number as hydro reported on the RELEASE_2_9_0 tag (in the hopes that they are in the same svn repository). I edited my .bashrc to include the HYRDRO_* env variables, opened up a new shell, built orca, and received the following error after having built and installed hydro: 

 CMake Error: Loading Hydro manifest - failed. Please reinstall Hydro, **
 delete CMakeCache.txt **, then re-run CMake.

After digging around, I see that the new trunk of hydro creates a manifest entry called HYDRO_MANIFEST_LOADED, which the 2.9.0 version does not provide. So, I downloaded the 2.9.0 release from sourceforge (rather than the svn tag). When doing this, I noticed that the .tgz file extracts to the directory hydro, rather than hydro-2.9.0. 

 sprinkle@macauslan-gutsy:/usr/local/src/hydro$ diff -r .

/home/sprinkle/svn/hydro-2.9.0/ | grep -v .svn 

 6,9d5
 < INCLUDE( ${HYDRO_CMAKE_DIR}/FindIceUtil.cmake )
 < REQUIRE_VAR( BUILD LIB ${LIB_NAME} ICEUTIL_FOUND "libIceUtil not found" )
 <
 <
 26a27,29
 >
 > # pretend CRaP distribution
 > ADD_SUBDIRECTORY ( crapurglaser )
 8,10d7
 < INCLUDE( ${HYDRO_CMAKE_DIR}/FindIceUtil.cmake )
 < REQUIRE_VAR( BUILD LIB ${LIB_NAME} ICEUTIL_FOUND "libIceUtil not found" )
 <
 sprinkle@macauslan-gutsy:/usr/local/src/hydro$

While it's a little troubling that the svn tag doesn't match the release, this clearly isn't indicative that hydro is causing the problem. When I diff the orca-2.9.0 release (file) versus the revision 4116, it's clear that this is the problem. So, I removed /opt/hydro-2.9.0 and rebuild and reinstalled hydro from the release .tar.gz, and edited my .bashrc file to produce the right environment variables, and resourced ~/.bashrc.

So, I started to build the orca-2.9.0 release (as downloaded from the sourceforge mirror), and it flat didn't work. In looking through why this didn't work, I noticed a file in the orca-2.9.0 release that contains an svn-commit.tmp~ file to include that structure as a tag, but it never got committed. Whoops.

Anyway, it turns out that the reason my orca-2.9.0 would not build was because I put my variable declarations in .bashrc after the default source for bash_completion. This is a recorded bug:

https://bugs.launchpad.net/ubuntu/+source/bash/+bug/160405 A duplicate of: https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/149527

While this is really annoying, I guess the next OS fixes it. Since I don't want to upgrade to an unstable OS, I comment out the source from my .bashrc for bash_completion, since (by god) it get sourced from /etc/bash.bashrc. Stupid ubuntu. :) This didn't bite me before, since I had opened a new shell.

So, now, cmake is happy, but the build fails when I run with `make -j2`. 

 [ 56%] Building CXX object

src/components/localnav/vfhdriver/CMakeFiles/OrcaLocalNavVfh.dir/vfhdriver.o 

 Linking CXX shared library libOrcaLocalNavTestSim.so
 /usr/bin/ld: cannot find -lOrcaPathPlan
 collect2: ld returned 1 exit status
 make[2]: *** [src/components/localnav/testsim/libOrcaLocalNavTestSim.so]

Error 1 

 make[1]: ***
 [src/components/localnav/testsim/CMakeFiles/OrcaLocalNavTestSim.dir/all]

Error 2 

 make[1]: *** Waiting for unfinished jobs....

I can only presume that there is a problem in cmake's dependencies here, and the dual compilation is crashing. So (without cleaning) I run make -j1. 

 [ 85%] Built target lasermon
 Linking CXX shared library libOrcaLocalNavTestSim.so
 /usr/bin/ld: cannot find -lOrcaPathPlan
 collect2: ld returned 1 exit status
 make[2]: *** [src/components/localnav/testsim/libOrcaLocalNavTestSim.so]

Error 1 

 make[1]: ***

[src/components/localnav/testsim/CMakeFiles/OrcaLocalNavTestSim.dir/all] Error 2 

 make: *** [all] Error 2

Now, I don't need this component, but why does it try to build if it doesn't work by default? In case it's a remainder problem from the beginning, I clean (read: remove build dir and start over) and do it again. 

 [ 86%] Building CXX object

src/components/localnav/testsim/CMakeFiles/OrcaLocalNavTestSim.dir/testsim.o Linking CXX shared library libOrcaLocalNavTestSim.so 

 /usr/bin/ld: cannot find -lOrcaPathPlan
 collect2: ld returned 1 exit status
 make[2]: *** [src/components/localnav/testsim/libOrcaLocalNavTestSim.so]

Error 1 

 make[1]: ***

[src/components/localnav/testsim/CMakeFiles/OrcaLocalNavTestSim.dir/all] Error 2 

 make: *** [all] Error 2

Now it's been 3 hours since a clean install of (k)ubuntu gutsy (7.10), and I still don't have a working copy of orca. After remembering from somewhere that having Qt installed can screw up everything, I checked out the Cmake output again:

-- Not planning to Build Library : OrcaPathPlan because libHydroPathPlan not installed

So, for some reason Orca still plans to build the test for localnav, despite the fact that localnav is not being built. Maybe this is fixed in a future release, or in the current trunk. In any case, it's not working in 2.9.0. I checked the hydro output:

-- Planning to Build Library : HydroPathPlan -- Looking for Qt4 >= 4.2 - not found -- Not planning to Build Library : HydroPathPlan because Qt4 not found

OK, so qt is messing all of this up, and not installing qt may have cost me a few hours. I wonder why building qt by default is not suggested? Maybe after building ice this would be reasonable? I install qt (though not player/stage) and after a few major downloads, orca and hydro are both happy.