Sunday, October 29, 2006

XCode debugger exited with status (1)

All of a sudden an XCode project which I was sharing with a collaborator refused to be debugged. The debugger was evidently exiting unexpectedly with "exited with status (1)" message. 

It took a long while to figure this out, but the project had been modified by my collaborator to hard code ppc generation. There were 3 such references in the project file. Had to change that to get the debugger to work again.

Wednesday, October 25, 2006

How not to use the boost singleton class

This is an odd and frustrating warning I was seeing while using the templated singleton class which comes with the boost C++ libraries while compiling under Visual Studio 2005. I used the following code to define a class which would be controlling a thread. It worked, but I was scared by the warning.

template< class T > class MySingleton : public boost::detail::thread::singleton < T >

class MyPayloadThread : public MySingleton< class MyPayload >


1>c:\src\hdrs\MySingleton.h(133) : warning C4624: 'MySingleton < T > ' : destructor could not be generated because a base class destructor is inaccessible
1> with
1> [
1> T=MyPayload
1> ]
1> c:\src\MySingleton.cpp(16) : see reference to class template instantiation 'MySingleTon < T > ' being compiled
1> with
1> [
1> T=MyPayload
1> ]

I did a lot of googling and couldn't find a direct answer to how I was supposed to give access to the singleton's private destructor. Then I had an epiphany about how I was supposed to use this class. The proper usage is:

typedef boost::detail::thread::singleton < class MyPayload > MyPayloadThread;

In retrospect, it's obvious that I couldn't sub-class singleton, I had to make use of it as a pure template.

Sunday, October 22, 2006

Wednesday, October 11, 2006

Tuesday, October 03, 2006

Setting up a Cheap Version Control Server for XCode

If you program, you need a version control system. We've all heard it, we all know it. But it's a trouble to setup and a pain in the pocketbook to dedicate a server, and even if you have a used computer free for the asking, it's still going to take up space and $10/month for electricity.

Because of a collaborative project, I felt an acute need for a version control system. My collaborator and I were spending much too much time stepping on each other's code trying to maintain a collection of source files via diffs and hand editing. So Sunday morning, I woke up with the resolve to set up a system.

My first thought was just to run a version control system on the Linux box I use for MythTV, but I've been rebooting into Windows XP every couple days to play Madden 06, and during the summer, when nothing much is on TV, I often turn it off to save energy. So it wouldn't be an ideal situation.

I thought of posts I've read about hacking NAS boxen to run Linux and a quick bit of googling came up with the consensus winner, the Linksys Storage Link for USB 2.0 Disk Drives NSLU2. This is a really cheap ($80), amazingly small, embedded Linux computer with 100 Base-T ethernet and 2 USB 2.0 ports. Plus it has an active development community of hackers extending what it can do.

I also decided to use a popular open source version control system Subversion (svn), if for no other reason that it isn't CVS, which I hate, or Perforce, which hates me.

Disclaimer: I am not a Linux expert. I am a decent Mac coder and software designer. You could very easily end up with a $80 paper weight, and not a good paper weight at that. Be careful.

Setting up the NSLU2
I am not going to go deep into setting up an NSLU2. I used the Unslung firmware, the instructions which came with the firmware, and the NSLU2-Linux HowTo.

Some important warnings about the process: test out the NSLU2 before modifying it. Bring it up in its unhacked form. Have it format your drive as EXT3. Make sure it works. Mount the shared volume on your Mac, copy some files, etc. The ethernet on the first unit I bought failed moments before I was going to flash its firmware, saving me from returning it modified. Think about your needs when it comes to hardware, I had a 60GB notebook drive in a compact USB 2.0 case lying on my desk; the capacity is fine for running a version control system, it's low power (it's actually powered by the two USB ports in the NSLU2), and I already had it. I used a cable tie to attach it to the NSLU2, and it became one, very portable solution. My Kill-A-Watt says the NSLU2 and the hard drive together draw 4W idling (9VA).
NSLU2+Hard Drive
NSLU2+Hard Drive Back

One thing I didn't take into account while setting this up is spinning the drive down to save noise and wear. According to this page, this is problematic and should be looked into before settling on a drive. I'm sitting at my desk 3 feet from the NSLU2 and I can definitely hear a bit of sandy whirl coming from the drive. Of course, the beauty of a server is that I can store it anywhere with an ethernet port and a electrical socket, like next to the upstairs router.]

[Update: I replaced the 2.5 inch drive with a standard 3.5 inch external USB drive, and that has been going strong for 2 years now. Having said that, I should look into backing it up.]

Use the NSLU2 web interface to give yourself an account with the same name as your account on your Mac. This will make ssh'ing into the unit just a bit easier. In the text below, I will use "jim" as a user name.

Again using the web interface, Give the NSLU2 a static IP address in the range used by your router, for example if your router uses 192.168.0.x IP addresses which is common.

Change the password for the admin account to something more secure.

Also make a group for all the collaborators of your project. Add yourself and the collaborator accounts to this group. This can all be done from the web interface. Make sure to give all these new accounts their own private folder.

At this point, you should have installed the new firmware, "unslung" Linux from running embedded to running off the USB 2.0 hard drive and been able to telnet into the box (Enable telnet from the web interface), and know your root password. Your NSLU2 is not going back to its old self, it's married to its hard drive.

I'm going to take over with the instructions.

Installing OpenSSH.
  • Telnet as root into the NSLU2 and install the OpenSSH package.
#ipgk update
#ipkg install unslung-feeds
#ipkg update
#ipkg install openssh
  • Reboot (unplug the NSLU2, plug it back in, push the on button, wait)
  • Turn Telnet back on via the Web Interface.
  • Telnet into the NSLU2
  • Edit the ssh server configuration file at /opt/etc/openssh/sshd_config (I used #sudo vi /opt/etc/openssh/sshd_config)

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes no
MaxAuthTries 6
RSAAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
  • If you like the bash shell, then
    #ipkg install bash
  • Make sure your user account is setup to take you to your home directory with your favorite shell by editting /etc/passwd

  • Edit /opt/etc/init.d/S40sshd by changing
/opt/sbin/sshd -f /opt/etc/openssh/sshd_config
  • Restart the NSLU2

So at this time, you should be able to ssh into the NSLU2 via a command like: ssh jim@ Confirm this is so, and if not remember that you can probably get back in via telnet. A point about what we have done. We disabled ssh as root because hackers might get lucky guessing your root password. My /var/log/messages file is filled with miscreants trying to get in as root.

Setting up public/private keys
[Update: I had had outdated instructions for setting up certificate based login here. OS X Leopard makes it much easier. Instructions Here.]

At this time, you should be able to ssh into your server without being asked for a password or passphrase as long as you are running SSH Agent. Now it's time to install svn.

Setting up the svn server
Subversion is a version control system. Version control systems are complex and have a high learning curve. Subversion is complex and has a high learning curve. There is a free O'Reilly book which covers its usage pretty well. At least read the Getting Started Chapter.
  • Install the svn package

#ipkg install svn

  • Copy the directory tree of the project for which you are starting source control onto the NSLU2 (let's say in /tmp/myproject)[Update: don't copy the build directory]
  • If you haven't already, create a directory for your project.
  • Make sure that your project group has access to this new directory.
  • Import the project under the control of svn

#mkdir /MyProject
#chown jim:myprojectgroup /MyProject
#cd /MyProject
#svnadmin create /MyProject
#svn import /tmp/myproject file:///MyProject/myproject -m "initial import"

At this time you should have a project under version control. You just need to be able to access it from your Mac.
Setting up the svn client on the Mac

[Update: Try to install the same version of subversion on your Mac as you do on the NSLU2. I had trouble with version 1.4 on the Mac and 1.3.2 on the NSLU2.
svn --version
Here are two ways to install Subversion:

1) Go this page on

2) Install Fink and use Fink Commander to keep installing packages until svn-client and svn-shlibs are listed as current. I found that fink balked at compiling all the pre-requisite libraries, but I could install those from binary and finally get svn itself to compile. It will take a while to compile.

At this point, you should have the svn client installed in your /sw/bin/ directory and be ready to checkout your project.

Checking out your project
  • Create a clean directory into which you want to check out your project.
  • Open up a Terminal window and cd into the newly created directory.
$svn checkout svn+ssh:// This is where it was important that you use the same user name for both the NSLU2 and your Mac. Notice I didn't have to specify "jim@". It was all implied.

At this point, you should have your project checked out onto your Mac.

Setting up XCode
  • Open up the XCode project file in your checked out project directory.
  • In the Groups And Files panel, choose the topmost blue project icon.
  • Right click on the project; select Get Info
  • In the General tab, choose Subversion as the SCM System
  • In the General tab, click the Edit... button. Enter /sw/bin/svn
  • In the General tab, click Enable SCM.

At this point, you should be able to commit changes, revert changes, and other basic source control functions from XCode's SCM menu.

Allowing outside collaborators access to the svn server
Obviously, a big part of source control is allowing outside collaborators access to your code. That's one of the big reasons we've gone to the trouble of using the ssh tunneling method for accessing the svn server. It should allow safer access to your network. But people outside your local area network will need to locate the NSLU2 from the Internet.

To do this, you will have to have a router which supports DynDNS. I have a previous blog entry about setting up a DynDNS account. In addition to the setup there, you will have to have your router redirect port 22 (ssh) traffic to the NSLU2. Do not do this until you are satisfied you are secure; it's a jungle out there.

Also, your collaborators will have to setup their own DSA public/private keys for their own accounts on the NSLU2. An easy way to download their private key is via CyberDuck. I had initially recommended the old standby Fugu, but I didn't have a Universal binary version of Fugu and when I looked for one, found a lot of positive feedback for CyberDuck. Just be sure to choose the SFTP option for the new connection.

At this point, you should have a network setup where a collaborator could checkout your project using a command like:
$svn checkout svn+ssh://

Good luck, and sorry if I missed anything.