Bill’s blog

I’m posting this because google is filled with unanswered questions and half-answers regarding this topic.

I’ve built Subversion 1.5.5 on a Solaris 10 sparc system using gcc. I had already set up a subversion server using the sunfreeware.com packages. However, I wanted to build my own self-contained subversion package to install on the other servers (”client-only” i guess, though there really is no such thing with subversion)

I was building this from source, because the subversion package on sunfreeware.com has too many dependencies and I was not interested in having to install all that extra stuff on every solaris box wishing to access my repository, especially packages like apache.

Step 1:
You will need to get the latest subversion source code. Make sure you get both the main package AND the dependencies package too!

Step 1b (optional):
If you require your subversion “clients” to talk to a subversion repository using ssl, you will need the Solaris openssl packages installed. Don’t try and build your own. I did, and later in this post you’ll see what happened. The Sun-supplied packages you will need to have installed on your system are:
SUNWopenssl-commands
SUNWopenssl-include
SUNWopenssl-libraries
SUNWopenssl-man
SUNWopensslr

Step 2:
Unpack the main package somewhere. Unpack the dependencies package on top of the main package.

I set the following environment variables:
LDFLAGS="-L /usr/local/lib -R /usr/local/lib -L /usr/sfw/lib -R /usr/sfw/lib -L /usr/lib -R /usr/lib"

LIBS="$LIBS -lintl"

Step 3:
Run the configure script. The configure options that worked for me in the end were:

--prefix=/opt/subversion
--with-ssl
--without-serf
--enable-shared="yes"
--enable-static="no"

Ignore any warnings it gives you about not finding BerkeleyDB. You don’t need it unless you are trying to access old repositories using that format. Any recent Subversion repositories are using the built-in fsfs format.

Step 4:
Run “make install” and you should be done!

Notes:

I ran into two problems which are extensively mentioned on subversion message boards. Here’s how I solved them:

1. Multiple inclusion of file errors while building neon libraries

/build/directory/.libs/libsvn_subr-1.so:
attempted multiple inclusion of file
Undefined first referenced
symbol in file
libintl_dgettext main.o (symbol belongs to implicit
dependency /usr/local/lib/libintl.so.8)
ld: fatal: Symbol referencing errors. No output written to .libs/svnadmin
collect2: ld returned 1 exit status

I fixed this by doing a two things:
- Make sure the $LIBS variable has “-lintl” included.
- Don’t build static libraries. I’m not sure why you would want to do this anyway. When running the top-level configure, include the options --enable-shared="yes" and --enable-static="no"

2. SSL disabled due to library version mismatch

When I was building this package, I wanted everything to be self-contained to reduce dependencies. So I downloaded openssl 0.9.8i and installed it in /opt/subversion prior to building subversion itself. However, no matter what I did, I was unable to stop getting this error, even when building neon separately and verifying via ldd that my binaries were all linking to the custom-built openssl libraries. I gave up and ended up just using the openssl 0.9.7 included in /usr/sfw/lib on Solaris 10. If you are like my workplace and install most of the OS packages on the servers, that library ought to be there, otherwise you will need to get your os media and install the packages manually. Once I set my LDFLAGS to include /usr/sfw/lib and rebuilt subversion, everything was ok. The neon-config script automatically includes /usr/sfw/lib, which I think is why most people are getting tripped up building subversion on Solaris 10. They may not install those packages with the OS.

This entry was posted on Wednesday, January 7th, 2009 at 12:11 pm and is filed under UNIX. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.