This is an old revision of the document!

SVN Installation




This covers installing subversion from a source tarball, for client-type uses. This document is based on an install of Subversion-1.4.3.tar.gz, but the install procedure should be similar for other versions as well. This does NOT cover installing Subversion as a server - some other steps are required for that. And it does not cover the procedure for compiling the 'bleeding-edges' version of subversion, which is a little different and more complicated (starting with the fact that you need subversion already installed in order to do it…?)

Required Software

For its functionality, subversion makes use of (depends on) a number or other pieces of software, all of which are also available for free. You must install these pieces of software before installing subversion. In many cases, some or all of the required software will already be installed on your system.

At the least, you will need to make sure these are installed correctly:

APR and APR-Util

These are the Apache Portable Runtime (APR) and its utility (APR-Util). Both must be version 0.9.7 or better. These provide a set of APIs that map to the OS - a layer between subversion and the OS which helps makes subversion platform independent. If you already have Apache2 installed then you already have the APR and APR-Util installed as well, so all you need to do is find them (more on that in Install APR and APR-Util)


zlib is a library with a number of compression and decompression functions, used by Subversion internally. This is usually installed so feel free to start the installation without checking, just remember that if the installation fails, it might be because zlib is not installed.

Neon - for older versions of Subversion

You will need neon installed in order to access the Greenstone repository over the internet, via WebDAV. Neon ensures that the subversion client program can handle repositories hosted on http, not just those on a local disk. (Also, if you are going to be hosting repositories over http, you will need neon so you can test those repositories.)

OpenSSL, Scons, Serf - for newer versions of Subversion (e.g. 1.8.18)

You will need to grab and compile up OpenSSL, grab and untar Scons and use this to compile up Serf.

A note on dependencies

Subversion offers a dependencies tarball, containing APR, APR-Util, Neon and zlib. Instructions on using this are in the INSTALL file in the root directory of the subversion tarball. However, if you are installing on a system which already has some of this software installed, a subversion installation which tries to install new copies of them might not go smoothly. For that reason, I recommend checking what you have and don't have installed on your system first, and installing what's missing yourself, before installing subversion.

Depending on the features of subversion that you wish to use, other software might be required for your installation. For example, if you want repository files stored in a BDB database rather than on disk, then BDB will need to be installed prior to installing subversion. For a first install, I recommend installing only the software listed above, as this is all that is required to get a good working subversion with all the main features. Advanced users can read the INSTALL file in the source tarball's root directory for more information on advanced features.


First install subversions dependency software, then install subversion itself. I prefer to store source code for a given piece of software in /research/oranfry/sources/<software-name-X.X.X> (where X.X.X is the version number) and install binaries to /research/oranfry/<software-name>. These install instructions reflect this preference, to please adjust them for your own preferences.

Install APR and APR-Util

If you have Apache2 If you have Apache2 installed, you don't need to install APR and APR-Util. They are both bundled with Apache2, so will already be installed on your system when it comes time to install subversion.

All you need to do for this step if you have Apache2 is to locate the apr-1-config and apu-1-config programs. They should be in the HTTPD_HOME/bin directory, and may be named slightly differently. For example, they might simply be named apr-config and apu-config. Remember the location of these programs for use in the last step, Install Subversion Itself

If you don't have Apache2 If you don't have Apache2, you will need to install APR and APR-Util. Download a recent version of each as .tar.gz tarballs from, then do the usual ./configure, make, make install. These commands need to be adjusted for the particular version you have downloaded.

#make a directory for my source code to go in
mkdir /research/oranfry/sources

#install apr
cd /research/oranfry/sources
tar -xzf /path/to/apr-X.X.X.tar.gz
cd apr-X.X.X
./configure --prefix=/research/oranfry/apr
make install

#install apr-util
cd ..
tar -xzf /path/to/apr-util-X.X.X.tar.gz
cd apr-util-X.X.X
./configure --prefix=/research/oranfry/apu --with-apr=/research/oranfry/apr
make install

When compiling apr, if you encounter the error

rm: cannot remove `libtoolT': No such file or directory

then follow the instructions at copied below

Edit your configure file

Change the line

    $RM "$cfgfile"


    $RM -f "$cfgfile"

This will resolve the error

    rm: cannot remove `libtoolT': No such file or directory

Then try run configure. That's it :)

Now locate the apr-1-config and apu-1-config programs. In my case they are were at /research/oranfry/apr/bin/apr-1-config and /research/oranfry/apu/bin/apu-1-config. The program binary files may be named slightly differently, for example, they could simply be named apr-config and apu-config. Remember the location of these programs for use in the last step, Install Subversion Itself.

Install zlib

This fairly standard-issue, so is probably installed on your system already. If you really want to check, you could try to compile a C program with #include<zlib.h> as the first line. If it compiles without error, zlib is installed. If not, installation instructions can be found at the zlib website.

Installing older versions of Subversion

Install Neon

Check if you have neon by running:

which neon-config

If you have neon, a path to neon-config will be outputted. Everything before /bin/neon/config is your neon home directory.

The neon version needs to be 0.25.x or greater. Check the neon version with:

neon-config --version

If you have a suitable version of neon, make a note of the neon home directory for use in the last step, Install Subversion Itself.

If you don't have neon, or need to install a newer version, get a recent copy it from the WebDAV website in a .tar.gz archive. Install it with:

cd /research/oranfry/sources
tar -xvf /path/to/neon-X.X.X.tar.gz (See note below)
cd neon-X.X.X
./configure --prefix=/research/oranfry/neon
make install

Note: if tar -xvzf doesn't work, try tar -xvf, since the neon.tar.gz file may not be gzipped.

Remember the neon home directory. In my case it is /research/oranfry/neon. This is used in the last step, Install Subversion Itself.

Install Subversion itself

Once all the required software is installed, subversion itself can finally be installed!

Download the most recent release of subversion (1.4.3 at the time of writing) from the Subversion website in .tar.gz format.

The basic installation sequence is below. Now is the time to make use of the paths to apr, apr-util and neon which you have noted down. Replace all paths with those for your own system. You may not need the –disable-neon-version-check switch - only use it if you have a very recent version of neon which svn mightn't know about yet.

cd /research/oranfry/sources
tar -xzf /path/to/subversion-X.X.X.tar.gz
cd subversion-X.X.X
./configure --prefix=/research/oranfry/subversion --without-apxs --with-apr=/research/oranfry/apr/bin/apr-1-config --with-apr-util=/research/oranfry/apu/bin/apu-1-config --disable-neon-version-check --with-neon=/research/oranfry/neon
make install

The configure may fail and require you to have sqlite3.c. The fail message will instruct you to grab the latest sqlite3 amalgamation tar.

For older versions of subversion, it will provide a link to the following version:, decompress it and copy the sqlite3.c into a special new subdirectory of your subversion-X.X.X folder.

mkdir /full/path/to/subversion-X.X.X/sqlite-amalgamation
cp sqlite-3.6.13/sqlite3.c /full/path/to/subversion-X.X.X/sqlite-amalgamation/sqlite3.c

After following these instructions in the fail message, re-run the configure step and then proceed to make and make install.

Now, subversion is installed in /research/oranfry/subversion. To use the svn command, put /research/oranfry/subversion/bin into your path.

Installing newer versions of Subversion like Subversion 1.8.18

You'd need apr and apr-util built and installed, as described further above.

I'm assuming we unpack the following tar.gz files into a sources folder and put their built installed versions into a packages folder.

1. Scons
Grab the tar.gz file at and unpack into a scons folder. (Unpacking the tar.gz file directly will put the script files at the same level as the tar.gz.)

cd sources
mkdir scons
mv scons-local-2.3.0.tar.gz scons/.
cd scons
tar -xvzf scons-local-2.3.0.tar.gz
(You can put the tar file back to where it used to be)

2. OpenSSL
Grab openssl from and unpack into sources folder.

cd sources
tar -xvzf openssl-1.0.2l.tar.gz
cd openssl-1.0.2l

export CFLAGS="-fPIC $CFLAGS" 
  # the above may or may not be needed for successfully compiling up Serf in step 3.
  # However the ''shared'' flag to the ./config command below is definitely
  # the solution that fixed Serf compile failures 

./config --openssldir=/Scratch/ak19/packages/openssl1.0.2l --shared
make install

The shared/–shared flag is necessary to successfully compile up serf against openssl hereafter. See the note in the Serf section.

When building openssl for GS, need to create static libs and disable shared libs:
./config –openssldir=/Scratch/ak19/packages/openssl1.0.2l –no-shared

–openssldir works like –prefix, but additionally puts bin, include, lib dirs with the openssl dir (which includes manuals) in the directory set with –openssldir.

–noshared builds as static, turns off shared. So this represents the usual combination of –enable-static –disable-shared. See or run ./configure –help

3. Serf
Grab and unpack serf from
Then use the unpacked scons from step 2 to compile and install Serf.

cd sources
tar -xvjf serf-1.3.9.tar.bz2
cd serf-1.3.9

  # flow on effect from OpenSSL, may not be required there nor here.

../scons/ APR=/Scratch/ak19/packages/apr1.6.2 APU=/Scratch/ak19/packages/apr-util1.6.2 OPENSSL=/Scratch/ak19/packages/openssl1.0.2l PREFIX=/Scratch/ak19/packages/serf1.3.9

../scons/ install

Between the configure and scons install steps, you may not need to bother doing the scons check step in the Serf README:
../scons/ check
The check step results in lots of failures, but it may not be essential, see

At the end of installing serf, the installed version of serf should contain lib and includes folders.

Note: When compiling up serf, if it fails with the error message

	/usr/bin/ld: /Scratch/ak19/packages/openssl1.0.2l/lib/libssl.a(s23_clnt.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
	/Scratch/ak19/packages/openssl1.0.2l/lib/libssl.a: error adding symbols: Bad value

then it may have nothing to do with exporting CFLAGS with -fPIC set, since setting this was at least insufficient to make the error go away.
Instead, it means that OpenSSL should have been compiled with enable-shared turned on, i.e. ./config shared … or ./config –shared … in step 2. See

4. Subversion
Can now at last compile up a new version of subversion with serf:

cd sources
tar -xvzf subversion-1.8.18.tar.gz
cd subversion-1.8.18

If you try configuring SVN 1.8.18, you may get an error about missing sql-lite. For subversion 1.8.18, follow the instructions that the configure error message provides:

get the sqlite amalgamation from:
unpack the archive using unzip and rename the resulting
directory to:

Then you'd re-run the configure command and onwards.

Alternatively, you can prepare your subversion package before configuring:

cd sources
mv sqlite-amalgamation-3071501 subversion-1.8.18/sqlite-amalgamation
  #needs to be renamed

Now proceed with the usual configure, make and make install. There are two locations in the configure command where Serf should be specified:

  # flow on effect from OpenSSL, may not be required there nor here.

LDFLAGS="-Wl,-rpath,/Scratch/ak19/packages/serf1.3.9/lib $LDFLAGS" ./configure --prefix=/Scratch/ak19/packages/subversion1.8.18 --without-apxs --with-apr=/Scratch/ak19/packages/apr1.6.2/bin/apr-1-config --with-apr-util=/Scratch/ak19/packages/apr-util1.6.2/bin/apu-1-config --with-serf=/Scratch/ak19/packages/serf1.3.9 [--disable-neon-version-check --with-neon=/Scratch/ak19/packages/neon]
[--disable-neon-version-check and --with-neon are no longer recognised.]
Try adding: --enable-shared

make install

Note: You need to prepend to the ./configure command the LDFLAGS set to the installed Serf's lib subfolder, else you'll be stuck always exporting LD_LIBRARY_PATH when running SVN, or exporting LD_LIBRARY_PATH from ~/.bashrc. Explained at

5. Add the installed SVN's bin folder to the PATH, such as by exporting it in ~/.bashrc, before running svn commands. In ~/.bashrc:

export PATH=/path/to/installed/svn/bin:$PATH
(export LD_LIBRARY_PATH=/Scratch/ak19/packages/serf1.3.9/lib:$LD_LIBRARY_PATH
  ## stuck doing this only if you didn't compile up Subversion with the 
  ## configure command's LDFLAGS set to Serf's ''lib'' folder.)

Installing Perl: compiling perl from source

The instructions are from Get the perl you want from, since the wget command didn't work for me. Then untar and follow along, substituting your perl version and a custom location that is not in the system area (like /usr or /opt):

tar -xzf perl-5.20.1.tar.gz
cd perl-5.20.1
./Configure -des -Dprefix=/path/to/non-system/location/where/you/want/your/installed/perl
make test
make install

Once it's finished compiling, your perl is ready for use. To do so: make sure to always first set up your PATH to point to your new perl's bin subfolder in any terminal which should use your locally installed perl rather than the system perl:

export PATH=/path/to/your/custom/compiled-and-installed/perl/bin:$PATH

Since you wouldn't have installed perl in a system location, uninstalling can be as simple as just removing the installed folder.