Many webhosts allow system executables (i.e. compiled programs) as CGI scripts. I am using this now (see
http://www.toyboxtoys.com/catalog.cgi for an example), and I really like the speed and the stability of it.
It's an interesting experience that will test your development capabilities though. The following tactics seem to work best:
1. Develop on the same platform that you will deploy on. If you're deploying on Solaris, develop on Solaris. If you're deploying on FreeBSD, develop on FreeBSD. You have some flexibility here. I develop on OpenBSD and depoy on FreeBSD, but I can only do this because both systems are very similar (the operating systems share a lot of code in common) and I am familiar with development on both of them. I wouldn't try this if the deploy system was Solaris or Linux, for example, and I wouldn't dream of developing on Windows and deploying on a UNIX system.
2. Expect to supply most external libraries that you'll be using, and link to them statically. Even if your web host has the libraries you need, they may be the wrong version, and they will upgrade on a different schedule than you will. In the example I provided above, I'm using three external libraries: libcgic and libgd from
www.boutell.com, and libmysqlclient. Because of size and compatibility, I had to use the system libmysqlclient, but I needed to supply the other two and link statically, even though one of them was provided by the system.
3. Learn your build tools well, because you'll be changing parameters to accomodate the differences in the development and deployment environments. For example, on my development system libcgic and libgd are both in /usr/local/lib, with necessary includes in /usr/local/include. On my deployment server, they're in ../cgic and ../gd. Since I don't want to change my code, I need to change linking and include paths passed to my compiler based on where I'm developing.
4. You need shell access to the deploy server, unless you can miraculously duplicate the deployment environment on your development system (including indentical versions and locations for all files). There are always subtle little differences between machines that will eventually trip you up.