Friday, July 22, 2005

installing subversion on solaris

Building Subversion 1.2 on Solaris 9

I’ve just spent a couple of days trying to get Subversion to build on a Solaris 9 environment. For some reason, it wasn’t as easy as it has been in the past and I’ve had a boat load of trouble, so I wanted to document the final solution I came to.

The Source Control System

We are running Solaris 9 and access the Subversion repository via HTTP/HTTPS through Apache. This means that I have to compile in SSL support for the client, in addition to mod_svn_dav support for the Apache Server. We also use the mod_svn_authz module for access control to the repository.

Software installed On The System

The following software is installed on the system:

Description of the Problem

The normal process I use for building these components is the following:

  1. Download the source tarball
  2. Untar the contents of the tarball to the a /tmp/subversion directory
  3. Configure the software with the following commands:
    ./configure --with-ssl --with-berkeley-db=/usr/local/BerkeleyDB4.2 --with-apxs=/usr/local/apache2/bin/apxs
  4. Build the software with the make command

The software builds until it hits the neon module, after which I would receive pages of the following errors:

make[1]: Entering directory `/tmp/subversion-1.2.0/neon'
cd src && make
make[2]: Entering directory `/tmp/subversion-1.2.0/neon/src'
/bin/bash ../libtool --quiet --mode=link gcc -rpath /usr/local/lib -version-info 24:7:0 -o ne_request.lo ne_session.lo ne_basic.lo ne_string.lo ne_uri.lo ne_dates.lo ne_alloc.lo ne_md5.lo ne_utils.lo ne_socket.lo ne_auth.lo ne_cookies.lo ne_redirect.lo ne_compress.lo ne_207.lo ne_xml.lo ne_props.lo ne_locks.lo ne_acl.lo ne_openssl.lo -lssl -lcrypto -lnsl -lsocket -lz /tmp/subversion-1.2.0/apr-util/xml/expat/lib/
Text relocation remains referenced
against symbol offset in file
0xd44 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd48 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd4c /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd50 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd54 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd58 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd5c /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd60 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd64 /usr/local/ssl/lib/libssl.a(t1_enc.o)
0xd68 /usr/local/ssl/lib/libssl.a(t1_enc.o)

When I saw the errors streaming across the screen, I remembered that I had gotten them before. To fix them previously, I changed into the neon directory and typed the following:

./configure --with-ssl --disable-shared

This had previously fixed the problem (I have no idea why). This time it didn’t and after rebuilding I had the same results.

Finally Getting Things To Build

On a fluke, I decided to run the shell script file in the neon directory and reconfigure neon, enabling shared libraries. Then I went back up to the root of the tree and built again. This time the software built cleanly and all tests ran successfully.

Installing The Software

Since I finally had a clean build and all tests had ran successfully, I decided to go ahead and install it. Upon installing it I received errors that linking failed on the shared libraries being installed and I had to relink everything. This pretty much rendered my source control unuseable until I could figure out why linking failed. Just to be clear, this was not on the production repository box, but on another Solaris machine.

I went through my /usr/local/bin and /usr/local/lib directory and removed every libsvn* shared library, all apr and apr-util shared libraries and all neon libraries that were present on the system. Once this completed, I was able to install the software successfully.

One of the symptoms of old libraries in the path or linking errors is the ‘undefined symbol’ error some have reported on the mailing list when upgrading. When you run into an error like this, you might want to try finding and removing all of these libraries as stated above, as this is an error I was getting as well. Removing the old directories and running make install fixed the problem.


This install was pretty painful. I attribute most of the pain to the fact that I was doing most of this work between meetings, so the constant start / stop took a toll on entering “flow state” to really think about the problem. As I was experiencing these problems, I couldn’t find any really good write ups on installation of the Subversion software on Solaris, so I figured I’d throw this together in the event that someone else was experiencing this level of frustration. Plus, I figure it will help me next time I need to do this to have an actual documented process to follow.

A summary of what I did follows, for those who don’t want to wade through this whole post again:

  1. After exploding the tarball, change to the neon directory and run
  2. Run the configure script with your desired options
  3. Build the software
  4. Run make check and ensure all of your tests pass
  5. Take the server down
  6. Back up your current installation
  7. Remove your old Subversion, apr, and neon libraries from the installed version
  8. Install the software
  9. Bring the server up
  10. Test

On the bright side, I also upgraded a SuSE 9.1 box to the new software. This took about five minutes after I found these RPM packages for SuSE 9.1.

Technorati Tags:

No Comments so far
Leave a comment

1 comment:

jcalcote said...

Thanks for the information. This article solved my build problems on Solaris. I think the reason that enabling shared libraries work for neon is that subversion wants to statically link to as many libraries as possible to reduce the possibility of a runtime problem due to installation of newer dependent libraries later. The trouble is that Solaris has a 16-bit relocation table by default - you have to enable the 32-bit address table by using the -k PIC option (as opposed to -k pic). The neon people should look into this issue on Solaris. When you compile shared libraries, the problem goes away, because the 32-bit tables are always used for shared object. Thanks again for your time.