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:

• OpenSSL 0.9.7g
• Berkeley DB 4.2
• Apache Web Server 2.0.50

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
   make
   

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 libneon.la 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/libexpat.la
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 autogen.sh 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.

Conclusion

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 autogen.sh
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.