How to install Subversion on a shared host
I’ve hosted this site and several others LiquidWeb’s shared servers for probably eight years. They are without question, the most dependable host I’ve ever used.
But LiquidWeb doesn’t offer Subversion. And I will no longer do web work without it.
For some time I’d been considering leaving LiquidWeb because the lack of svn was now hindering work on my own sites. For the same reason, I’ve had to pass them over several times when clients asked for hosting recommendations. Then the other night, I stumbled across a discussion about installing Subversion on a shared host. Why didn’t I try that years ago?
Installation Instructions
These instructions assume basic proficiency with the Unix command line. Note that the goal is to install the SVN client, plan on hosting your repositories somewhere else.
Connect to your account with ssh and create a working directory, mine’s called _src:
cd
mkdir _src
cd _src
Next, use wget to pull down the subversion sources. You could also use curl, but wget does the same with less typing. Choose a version from this list of Subversion sources. The parallel “subversion-deps” download includes all dependent sources required to build Subversion.
wget http://subversion.tigris.org/downloads/subversion-1.4.6.tar.gz
wget http://subversion.tigris.org/downloads/subversion-deps-1.4.6.tar.gz
Next, untar the sources and dive into the directory:
tar -xzvf subversion-1.4.6.tar.gz
tar -xzvf subversion-deps-1.4.6.tar.gz
cd subversion-1.4.6
One step, maybe (32-bit?)
At this point, depending on your server configuration, you might be able to install with the following two commands:
./configure --prefix=$HOME --without-berkeley-db \
--with-ssl --with-editor=/usr/bin/vim \
--without-apxs --without-apache
make && make install
That worked on some servers but not others, I spent many hours clumsily trying to figure out why. I found that the build process was linking to external libraries instead of the ones in subversion-deps, despite the configure directives.
On the 64-bit server (x86_64) this was a big problem, even though everything worked normally on two 32-bit (i686/i386) servers. Check server architecture with either arch, uname -a or cat /proc/cpuinfo. The solution for 64-bit machines is to build the three main components beforehand and then tell Subversion where to find them.
Build them, use them (64-bit?)
The following commands systematically build each of the three shared libraries from the Subversion-deps sources. This should guarantee that the files Subversion links to will be compatible. In each step, we explicitly enable compilation of shared libraries and prefix the files into our home directory. This looks worse than it is.
Build apr, apr-util and neon, in that order:
cd apr
./configure --enable-shared --prefix=$HOME
make && make install
cd ../apr-util
./configure --enable-shared --prefix=$HOME \
--with-expat=builtin --with-apr=$HOME \
--without-berlekey-db
make && make install
cd ../neon
./configure --enable-shared --prefix=$HOME \
--with-libs=$HOME --with-ssl
make && make install
With those out of the way, we can now configure and build Subversion. According to the notes in Subversion’s configure file, the --with-ssl flag is not necessary since it’s just passed to neon and we already built neon. --without-apxs and --without-apache prevent Subversion from trying to install its Apache modules. Remember to point to the libraries we just built (in $HOME):
cd ../
./configure --prefix=$HOME --without-berlekey-db \
--with-editor=/usr/bin/vim --with-apr=$HOME \
--with-apr-util=$HOME --with-neon=$HOME \
--without-apxs --without-apache
make && make install
Subversion should now be installed! It’s likely you already have :~/bin in your user $PATH, if so, you can try it out right away:
svn --version
svn, version 1.4.6 (r28521)
compiled Jan 29 2008, 11:05:47
So far, I’ve run this against two LiquidWeb shared accounts, one LiquidWeb CPanel container on a VPS and a HostingMatters shared account running JailShell. After some limited testing accessing different repositories with https and svn+ssh, everything seems to be working.
Now I just need to figure out where to put my repositories, here are some free Subversion hosts I’ve used or are considering:
- Beanstalk 20 MB free
- Assembla 500 MB free?! really?
- Unfuddle 15 MB free
- Google Code 100 MB free, must be open source
Two other sites which aren’t free, but I’m keeping in mind for the future: Wush and Project Locker.
The getting there was the hardest part
While I was finally able to streamline this down to a fairly simple process, it was not easy to get there. I don’t do much compiling from source, so I’m very clumsy about troubleshooting. If any of these steps can be simplified, please leave a note.
Here are some of the errors I saw along the way:
/usr/lib/libexpat.so: could not read symbols: File in wrong format
/usr/lib/libexpat.so: could not read symbols: Invalid operation
/home/joe/_src/subversion-1.4.6/neon/src/.libs/libneon.a: could not read symbols: Bad value
The first two errors indicate that the build had grabbed the 32-bit libexpat from /usr/lib instead of the 64-bit version from /usr/lib64. However, redirecting to the 64-bit libraries introduced other problems such as the libneon.a bad value error. As mentioned above, what I needed to do was pull libraries from the subverson-deps code. To use those, I needed to compile each one first.
Resources:
- Subversion’s INSTALL file
- ./configure -help
- These commands, from this original post almost worked.
- Installing Mephisto and Subversion on a Shared Host, first inkling this was possible
- similar problem with with /usr/lib instead of /usr/lib64.
- GATTAGA’s post was the first clue about working around the libexpat problem.
- SVNforum: libneon.a: could not read symbols: Bad value This was the post that gave me the final bit of information I needed
Disclosure: Links to LiquidWeb are affiliate links. I couldn’t really come up with a good reason not to let them pay me for bringing them customers. They really are a fantastically reliable host.

Thanks for this great step by step guide. I am trying to install SVN on Bluehost.com, following the steps above but keep getting this error on the final SVN make install command:
/usr/bin/ld: /home/prospet5/lib/libneon.a(ne_request.o): relocation R_X86_64_32 against `a local symbol’ can not be used when making a shared object; recompile with -fPIC
/home/prospet5/lib/libneon.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [subversion/libsvn_ra_dav/libsvn_ra_dav-1.la] Error 1
I would be grateful for any help with my issue. Thanks again.
Sorry, a bit more info - uname -a returns:
Linux box347.bluehost.com 2.6.22-9_1.BHsmp #1 SMP Fri Sep 28 23:36:16 MDT 2007 x86_64 x86_64 x86_64 GNU/Linux
@David, I think the ld warning is saying it can’t read the locally installed libneon. Did you follow the 64-bit instructions? And if you did, did you paste them as one block or enter the commands one at a time? Were there errors with the make && make install for the neon library?
Hi Joe,
I pasted the commmands one at a time. These errors are happending with the make install for subversion at the end of the process you outline above.
How would I see if there were errors with the make && make install for the neon library?
Thanks for the info… regards… navtej kohli.
@David McDonald Try splitting the “make” and “make install” onto separate lines, I suspect there might be an error after neon’s make command, if not sooner. I looked into setting up an account at BlueHost, but they’re kind of expensive for short-term accounts. I think I’ve got a similar server on an account with A2hosting, I’ll give it a try there and see what happens.
Thanks for the help–I’ve learned snippets of this stuff on my own, but your solution was comprehensive, and helped me out of a Neon hole.
Morgan
One thing I should mention, to get rid of the “libneon.a: could not read symbols: Bad value” error, another poster at SVNForum.org mentioned having to set the environment variable
EXTRA_CFLAGS=-L/usr/lib64 -fPIC
It turns out that the neon directory needs the same flags, but doesn’t read them from the same $EXTRA_CFLAGS env variable. In building neon, you ALSO have to set
CFLAGS=-L/usr/lib64 -fPIC
Argh! It’s not like 64-bit is leading edge at this point!
Morgan
@David McDonald
I found the solution to this at http://yavin4.anshul.info/category/linux/
neon should be compiled seperately, using –enable-shared with configure.
So I did:
svn-1.4.6/neon]$ ./configure –prefix=/home/myuser/system –enable-shared
svn-1.4.6/neon]$ make && make install
svn-1.4.6/neon]$ cd ..
svn-1.4.6]$ ./configure –prefix=/home/myuser/system
svn-1.4.6]$ make && make install
and that got things running.
Joe,
Thanks so much! I just upgraded to a 64bit CentOS VPS and my usual compile methods failed. I found this blog post and your 64bit instructions saved me big time. It worked perfectly.
Thanks for putting this info out here. I too rely on svn for web work.
Shrop
With an enormous amount of help from Colin, I finally got SVN working on Bluehost on a 64 bit box. Here’s how I did it if anyone is interested.