If running SubVersion behind Apache HTTPD is a bit too much for your purposes, you could configure svnserve into launchd on the mac. That way your repositories are hosted by svnserve on demand.

Read more about how to do that on this URL:
http://marc.baffl.co.uk/stuff.php#svnserv-plist

Thanks for the article. I installed the dmg and made the changes to my httpd.conf file however I am getting the following error when I start apache.

httpd: Syntax error on line 116 of /private/etc/apache2/httpd.conf: Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: dlopen(/opt/subversion/lib/svn-apache/mod_dav_svn.so, 10): Library not loaded: /opt/subversion/lib/libaprutil-1.0.dylib\n Referenced from: /opt/subversion/lib/svn-apache/mod_dav_svn.so\n Reason: Incompatible library version: mod_dav_svn.so requires version 4.0.0 or later, but libaprutil-1.0.dylib provides version 3.0.0

I don't know if I need to use
LoadModule dav_svn_module /opt/subversion/lib/svn-apache/mod_dav_svn.dylib
because that did not work so I changed the ext to .so (there was no dylib file in that folder)

I also tried updating /usr/sbin/envvars but I also received other errors. Any clue based on this error why this would not work?

I have updated to 10.5.7 the other day so I'm not sure if that has anything to do with it.

Thanks!

Niels,
You are right. You should be using ".so" extensions for the Apache Subversion modules. I'm not sure if you followed the instructions or not but if you updated the /usr/sbin/envvars to either remove the DYLD_LIBRARY_PATH environment variable or you set it to have /opt/subversion/lib in the front, that should work. I have Apache serving Subversion with the same Subversion client and Apache modules shipped in the binary so there has to be some sort of disconnect between what I have configured and what you have configured.

I believe I've followed your instructions to the letter on 2 Macs and am getting the same error with each:

dyld: Symbol not found: _apr_socket_sendfile
Referenced from: /usr/sbin/httpd
Expected in: /opt/subversion/lib/libapr-1.0.dylib

I've updated the envvars to read:
DYLD_LIBRARY_PATH="/opt/subversion/lib:/usr/lib:$DYLD_LIBRARY_PATH"

Any advice would be appreciated.

Why is the new install path /opt? OS X does not have this path by default. Using that path creates a new root level directory just for subversion. Is there a reason /usr/local was not acceptable?

BL,
Can you provide more information about your system:

OS X version
Apache version

I've not had this reported before.

Jesen,
The purpose of this was to create an installation location what would not conflict with any other Subversion installation. /opt is a standard location for optional software and so it seemed like a good place. I did install to /usr/local early on but it conflicted with some other Subversion installations like SCPlugin. Subversion developers also reported it was causing build anomalies. That's when I decided to put it in an isolated place to help avoid conflicts.

Jeremy,

Thanks for getting back to me. I'm running the latest version of OS X: 10.5.7 with the default Apache install of 2.2.11 and I've tried this on both an iMac and a Mac Mini.

BL,
My last question is are you on a PPC-based Mac or an Intel-based Mac? I'm still not seeing anything like this reported before. I'll keep digging while you respond.

Take care,

Jeremy

They are both intel based. I've also got a intel macbook lying around so after a backup this weekend I'll have a go at getting it setup on there.

BL,
I think I have figured this out. How are you loading the Subversion Apache modules? The mod_dav_svn you're loading appears to be looking for an APR that has sendfile defined. I do not build apr with sendfile to work around a bug. It sounds like you're loading the Subversion Apache modules shipped either with Leopard or with another binary that isn't mine yet you're telling Apache to use the libraries shipped with my binary. Can you tell me how you're loading the Apache modules?

Hi Jeremy,

I'm having the exact same problem as BL, and same system config. I first got the DYLIB error, now getting the _apr_socket_sendfile error.

I followed the instructions above to the letter, but could this be an issue:

httpd.conf
----------
..

LoadModule dav_module libexec/apache2/mod_dav.so

.. (then at the end the new block:)

# Load Subversion Apache Modules
LoadModule dav_svn_module /opt/subversion/lib/svn-apache/mod_dav_svn.dylib

# Work around authz and SVNListParentPath issue
RedirectMatch ^(/svn/imi_repos)$ $1/

# Enable Subversion logging
CustomLog logs/svn_logfile "%t %u %{SVN-ACTION}e" env=SVN-ACTION

# Enable Subversion
DAV svn

# Directory containing all repository for this path
SVNParentPath /Users/chada/Desktop/Archive/Projects/IMI-Web

# List repositories collection
SVNListParentPath On

Sorry, that wasn't too clear, I meant following up on your conjecture that a native apache library was looking for the missing symbol in your modules, I noticed that the regular dav_module was being loaded from the regular filesystem and then dav_svn_module is being loaded from your custom code.

Just a stab. I'm a newbie ;)

Well, it should be "/opt/subversion/lib/svn-apache/mod_dav_svn.so" instead of "/opt/subversion/lib/svn-apache/mod_dav_svn.dylib". I'm not sure if that is what you meant from "DYLIB error" or not. As for mod_dav being loaded the way it is, that's no problem. I just wanted to make sure BL and yourself were loading the Subversion Apache modules from /opt/subversion/lib/svn-apache.

The more I look around, to try and figure out why my environment works and yours doesn't, I realize that my /usr/sbin/envvars and I see that I don't have DYLD_LIBRARY_PATH defined. I have that line commented out. Maybe you can try that. I'm at a loss. That's the only thing I can see that is different between what I've put into my blog entry and what I have locally (working).

Jeremy: Commenting out DYLD_LIBRARY_PATH from my /usr/sbin/envvars (and /usr/sbin/envvars-std to be safe) solved the "dyld: Symbol not found: _apr_socket_sendfile" problem on my system. We'll see if it causes other problems, but for now, at least dav_svn seems to be working.

Thanks for the info!

Yes, Jeremy, this is a great article! Something this comprehensive was hard to come by.

I changed .dylib to .so in httpd.conf, commented out DYLD_LIBRARY_PATH from /usr/sbin/envvars, and apache starts up fine.

The next 2 problems I had were solved by 1.) creating the file /usr/logs/svn_logfile which was of course absent, and starting up Web Sharing in the System Preferences.

Now, I'm back to a permissions problem, as when I try to access http://localhost/svn/imi_repos/trunk/, I get " Could not open the requested svn filesystem", although http://localhost/svn/imi_repos shows the regular small list of svn top level links ("branches","trunk", etc).

I did run the command: sudo chown -R www:www /Users/chada/Desktop/Archive/Projects/IMI-Web

and it chown's to _www instead of www. Is this normal or is this a symptom of something else?

I don't know why /usr/logs was required to be created. It should log to the same place Apache logs the access and errors to. Regardless, glad to hear you got it working. As for permissions, yes, _www is expected.

I have updated the article to fix the name of mod_dav_svn and also to add a note about updating /usr/sbin/envvars.

Hi Jeremy, Very good post. I'm having the same trouble with the envvars paths and getting an error looking for sendfile. Here are the scenarios:

with DYLD_LIBRARY_PATH completely commented out (with the export statement) which in my case leaves a completely empty envvars file. I get the following error when i try to start apache with apachectl -k start:

httpd: Syntax error on line 118 of /private/etc/apache2/httpd.conf: Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: dlopen(/opt/subversion/lib/svn-apache/mod_dav_svn.so, 10): Symbol not found: _dav_push_error\n Referenced from: /opt/subversion/lib/svn-apache/mod_dav_svn.so\n Expected in: flat namespace\n

with DYLD_LIBRARY_PATH defined as:
DYLD_LIBRARY_PATH="/opt/subversion/lib"
export DYLD_LIBRARY_PATH

I get the following error when i try to start apache with apachectl -k start:

dyld: Symbol not found: _apr_socket_sendfile
Referenced from: /usr/sbin/httpd
Expected in: /opt/subversion/lib/libapr-1.0.dylib

Ben,
Can you tell me a little more about your environment? OS version, CPU architecture and Subversion version are most important. We'll go from there.

Take care,

Jeremy

thanks for the help.

OSX 10.5.6
Dual PowerPC G5 CPUs

SVN version: 1.6.2 (r37639) compiled May 14 2009
(from the collabnet package)

Hi Ben

ok the problem you are experiencing seems to be related to the OS X factory version of Apache.
it looks for the sendfile symbol in the libapr-1.0.dylib. The subversion version (universal installer) of this file does not seem to have this symbol in it. It may be possible to compile the subversion libs to include this but I have not yet needed to investigate that possibility.
The standard version 1.0.2.7 of this in /usr/lib has the sendfile symbol and so the webserver works out of the box.
that is why uncommenting the path makes it work again.

i would suggest that you relink the /opt/subversion/lib/libapr-1.0 back to the original in the /usr/lib folder
possibly the libaprutil could be involved too?

then you can uncomment the added DYLD_LIBRARY_PATH in your config for the subversion lib folder

I dont use the apache server at all for my subversion work but managed to get my break my web sharing with the same problem.

HTH

relinking is a bit beyond my experience. Would reinstalling apache from another binary package work?

Well, I can rebuild the binary with the apr symbol but that doesn't really fix what's going on here. If you have any request to resolve the '_apr_socket_sendfile', you're loading the wrong version of APR at runtime. Relinking shouldn't help. While I was thinking it could be how I'm building the 4-way universal binary, the error you are getting means there is a problem is do to your mod_dav_svn.so loading apr delivered with Leopard instead of the one I link against and ship with my binary. Something is mucking with your loader path. Aaron above was successful in getting this binary working by just uncommenting the two lines in the /usr/sbin/envvars file.

I'll look into another way to handle this when 1.6.3 comes out if possible.

Hi Jeremy,
I am trying to set up my svn server to work over ssh. It looks like there is no way to do that short of recompiling sshd
The reason:
sshd comes with a precompiled PATH (/usr/bin:/bin:/usr/sbin:/sbin)

Adding export PATH=/opt/subversion/bin:$PATH to bashrc does not work for ssh remote commands (ssh doesn't seem to create a shell when executing remote commands):

ssh [username]@[host] svn --version
svn, version 1.4.4

ssh [username]@[host]
# svn --version
svn, version 1.6.2

As a result, I get this when I try to check out:
Expected FS format ‘2′ ; found format ‘4′

Any ideas?
Thank you,
Florin

I did everything as described, but still get
"cannot load ... mod_dav_svn.so into server: (reason unknown)".
from within the Server-Admin-Application.

I did this on my XServe runnig
Mac OS X Server, Version 10.5.7. 2x2GHz Dual-Core Intel Xeon, 2GB RAM

SVN version: 1.6.2 (r37639) compiled May 14 2009
(from the collabnet package)

Florin,
That means that you have created a repository with a newer Subversion library but are trying to use it locally with an older library, which isn't possible. Update your PATH so that you use the newest Subversion binary and this should not be an issue.

Stefan,
"(reason unknown)" is something I've not run into before. Can you try starting up Apache from the command line to see if you can get a useful error? Maybe even look in the Apache error logs. Let me know and we'll continue.

Take care,

Jeremy

Hi Jeremy,
I am trying to set up a svn server and access it remotely over ssh.
I was trying to point out that:
1. OS X comes with an older version of svn in /usr/bin
2. Your package installs the newer svn in /opt/subversion/bin
3. The library that connects to the server (in my case, Eclpse SvnKit) issues remote commands to server over ssh.
4. The remote commands are always executed on the server by the older svn binary because sshd has a built-in path (/usr/bin:/bin:/usr/sbin:/sbin).
This means that trying to access a new repository over ssh (svn+ssh://user@host/path) does not work even if I update the PATH.
For now I will stick with the old version.
Thanks,
Florin

I'm having the same problem Florin had. I am running 1.6.3 on both my server (PPC XServe) and my client (Intel MacBook Pro). When I try svn+ssh, I get "Expected FS format ‘2′ ; found format ‘4′" even though "svn --version" locally and remotely returns 1.6.3. Any ideas? Thank you!

Well guys, this is an environment issue. The binary works fine and your problem has nothing to do with the CPU architecture. The reason for the problem is that when accessing via SSH, your PATH environment variable doesn't have /opt/subversion/bin in front of /usr/bin, so that you use the newer binary instead of the one shipped with Leopard. This is an SSH configuration issue that can be solved a few different ways. One would be to update the /etc/sshd_config to enable the AcceptEnv option and then you can configure your client using /etc/ssh_config. This is common practice and has nothing to do with Subversion.

Good luck.

I'm having the same problem as Stephan above. This is the output of sudo apachectl start:
mini:/opt russell$ sudo apachectl start
Processing config directory: /private/etc/httpd/users/*.conf
Processing config file: /private/etc/httpd/users/russell.conf
Processing config directory: /etc/httpd/conf.d/*.conf
Processing config file: /etc/httpd/conf.d/svn.conf
Syntax error on line 2 of /etc/httpd/conf.d/svn.conf:
Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: (reason unknown)
/usr/sbin/apachectl start: httpd could not be started

There is no output in /var/log/httpd/error_log

The host operating system is OS X 10.4.11 Build 8S165 running on a Mac Mini PowerPC G4

I get the same error when trying to install Subversion 1.5.6, 1.6.1 and 1.6.3

Any ideas? Thanks.

I'm currently working on getting access to a PPC-based Mac. I won't be able to do this alone until then. In the mean time, can you try to start Apache without apachectl to see if you get any extra information? Just "sudo httpd". What happens?

Hi Jeremy,

This is the output for sudo httpd

mini:~ russell$ sudo httpd
Password:
Processing config directory: /private/etc/httpd/users/*.conf
Processing config file: /private/etc/httpd/users/russell.conf
Processing config directory: /etc/httpd/conf.d/*.conf
Processing config file: /etc/httpd/conf.d/svn.conf
Syntax error on line 2 of /etc/httpd/conf.d/svn.conf:
Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: (reason unknown)

No output in /var/log/httpd

Just for grins, can you both run "httpd -v" to get the Apache version? If it's not Apache 2.2.x, that would explain this.

I have a new Mac Pro with OS X 10.5.7,
Apache/2.2.11 (Unix), and
svn, version 1.6.2 (r37639).
I followed your instructions exactly
and studied your dialogs with Florin et al.

I put your LoadModule and RedirectMatch stuff in http-subversion.conf and
added "Include /private/etc/apache2/extra/httpd-subversion.conf" to httpd.conf.

I commented out the two DYLD_LIBRARY_PATH lines in envvars-std.

With envvars configured as follows:
DYLD_LIBRARY_PATH="/opt/subversion/lib:/usr/lib:$DYLD_LIBRARY_PATH"
export DYLD_LIBRARY_PATH
I got the same error others got after "sudo apachectl -k start"
dyld: Symbol not found: _apr_socket_sendfile
Referenced from: /usr/sbin/httpd
Expected in: /opt/subversion/lib/libapr-1.0.dylib

When I comment out the two DYLD_LIBRARY_PATH lines in envvars,
I get no response at all after running "sudo apachectl -k start".
I keep a separate Terminal shell running with top and httpd doesn't even pop up.

I don't know what else to try. By the way, I downloaded a great Show Hidden Files.app from http://automatorworld.com/archives/show-hidden-files/

Well, if you commented out the two lines in /etc/envvars and you get no output when you start Apache, that's good. When you start Apache with "sudo httpd" or "sudo apachectl", you should have nothing returned to you but your terminal if things go as expected. To verify this, after starting Apache, "sudo ps aux | grep 'httpd'" to see the httpd processes or you can browse to the localhost to see that Apache is indeed working. Can you try this and let me know?

Hi Jeremy,

That'd be it then, Tiger ships with 1.3:

mini:~ russell$ httpd -v
Server version: Apache/1.3.41 (Darwin)
Server built: Feb 22 2008 09:40:00

Well, for me that is great news. ;)

I should learn to read the pre-requisite list before installing ;)

I went back to svn 1.4.4
I will try svn 1.6.2 another time.
Thanks

Philip,
Can you see if any of the comment above shed light on the subject? It appears some people with the same issue with you were due to either the wrong version of Apache or not following the document completely so that all lines in envvars were commented out. 1.4.x is such an old version that I'd hate to see you go back because of this. If you can tell me anything more, I'd love to help:

CPU Type
OS Version
Apache Version
Exact Error

Yes...I know you've posted some of this in the past but I'd like one location for all of this.

Have you setup svnserver in Mac OS X Server Snow Leopard?

I am trying to setup access for different repositories to be based off of the group from Open Directory.

I actually had to point the dav_svn to my apache version on snow leopard to get rid of my seg faults.

Here is the change I had to make to get everything working.

# Load Subversion Apache Modules
# LoadModule dav_svn_module /opt/subversion/lib/svn-apache/mod_dav_svn.so
LoadModule dav_svn_module libexec/apache2/mod_dav_svn.so

I don't know why the collab module was having a problem, could just be that snow leopard is still so new.

John,
Yes...I'm currently tracking down a problem with my binary on Snow Leopard. The good news is the problem only appears to happen with Apache. Sorry for the inconvenience.

Take care,

Jeremy

I tried installing Subversion 1.6.6 (tried 1.6.5 before same resuts) on Dual 1.8 Ghz G5 power mac with Leopard Server 10.5.8 v1.1.

I believe I followed the directions:
but I still get the the error

$ apachectl -t
dyld: Symbol not found: _apr_socket_sendfile
Referenced from: /usr/sbin/httpd
Expected in: /usr/lib/libapr-1.0.dylib

/usr/sbin/apachectl: line 81: 3445 Trace/BPT trap $HTTPD $ARGV

I did comment out lines in /usr/sbin/envvars and envvars-std

The difference in my installation is that I want to be able to use xcode and for that (as per other comments on other websites)
I have to change the symlinks in /usr/lib
and also copy the apache modules to /usr/libexec/apache2.

Any idea why its not working.

I tried this several times and to make it easy to go back and forth I wrote a couple of shell scripts to automate the process.
So you can see exactly what I did.

-----------------------------
#!/bin/bash -
# svnsymlink.sh
# Sam Smith 20091022

BACKUPLIB="/backup/subversion/usr/lib"

echo ""
echo "Backing up subversion installation to $BACKUPLIB"

sudo mkdir -pv "$BACKUPLIB"

#cp -Rpv #-R copies symbolic links without following them, p preserves permissions

sudo cp -Rpv /usr/lib/libap*-1.dylib "$BACKUPLIB" #copies symlink or file if not symlink
sudo cp -Rpv /usr/lib/libap*-1.0.dylib "$BACKUPLIB"
sudo cp -Rpv /usr/lib/libsvn*-1.dylib "$BACKUPLIB"
sudo cp -Rpv /usr/lib/libsvn*-1.0.dylib "$BACKUPLIB"

echo ""
echo "Removing old symlinks"
sudo rm -v /usr/lib/libap*-1.dylib
sudo rm -v /usr/lib/libap*-1.0.dylib
sudo rm -v /usr/lib/libsvn*-1.dylib
sudo rm -v /usr/lib/libsvn*-1.0.dylib

echo ""
echo "Installing new symlinks"
sudo ln -sv /opt/subversion/lib/*-1.0.dylib /usr/lib/
sudo ln -sv /opt/subversion/lib/*-1.dylib /usr/lib/

#fix up ra-dav symlink to point to ra-neon
echo ""
echo "Fixing ra_dav to point to ra_neon symlinks"
sudo ln -sv /usr/lib/libsvn_ra_neon-1.dylib /usr/lib/libsvn_ra_dav-1.dylib
sudo ln -sv /usr/lib/libsvn_ra_neon-1.0.dylib /usr/lib/libsvn_ra_dav-1.0.dylib

BACKUPAPACHE="/backup/subversion/usr/libexec/apache2"

echo ""
echo "Backing up subversion apache modules $BACKUPAPACHE"

sudo mkdir -pv "$BACKUPAPACHE"
sudo cp -Rpv /usr/libexec/apache2/mod_dav_svn.so "$BACKUPAPACHE" #copies symlink or file if not symlink
sudo cp -Rpv /usr/libexec/apache2/mod_authz_svn.so "$BACKUPAPACHE"

echo ""
echo "Removing old modules"
sudo rm -v /usr/libexec/apache2/mod_dav_svn.so
sudo rm -v /usr/libexec/apache2/mod_authz_svn.so

echo "Installing new modules"
sudo cp -Rpv /opt/subversion/lib/svn-apache/mod_dav_svn.so /usr/libexec/apache2/mod_dav_svn.so
sudo cp -Rpv /opt/subversion/lib/svn-apache/mod_authz_svn.so /usr/libexec/apache2/mod_authz_svn.so

echo ""
echo "Now fix /usr/sbin/envvars and envvars-std and restart apache"

echo ""
echo "Completed installation!"

exit

-----------------------
#!/bin/bash -
# unsymlink.sh
# Sam Smith 20091022

BACKUPLIB="/backup/subversion/usr/lib"

echo ""
echo "Restoring subversion installation from $BACKUPLIB"

echo ""
echo "Removing new symlinks"
sudo rm -v /usr/lib/libap*-1.dylib
sudo rm -v /usr/lib/libap*-1.0.dylib
sudo rm -v /usr/lib/libsvn*-1.dylib
sudo rm -v /usr/lib/libsvn*-1.0.dylib

echo ""
echo "Restoring old symlinks"
sudo cp -Rpv $BACKUPLIB/*.dylib /usr/lib

BACKUPAPACHE="/backup/subversion/usr/libexec/apache2"

echo ""
echo "Restoring old subversion apache modules from $BACKUPAPACHE"

echo ""
echo "Removing new modules"
sudo rm -v /usr/libexec/apache2/mod_dav_svn.so
sudo rm -v /usr/libexec/apache2/mod_authz_svn.so

echo "Restoring old modules"
sudo cp -Rpv $BACKUPAPACHE/mod_dav_svn.so /usr/libexec/apache2/mod_dav_svn.so
sudo cp -Rpv $BACKUPAPACHE/mod_authz_svn.so /usr/libexec/apache2/mod_authz_svn.so

echo ""
echo "Now fix /usr/sbin/envvars and envvars-std and restart apache"

echo ""
echo "Completed restoration!"

exit

Do you know if Apache worked before you mucked with the system-shipped libs? Also, installing the Subversion Apache modules I ship should not be referenced elsewhere so when your script tries to copy them to /usr/libexec/apache2/, I don't think that's a good idea either. As much mucking around as you've done, I'm not surprised that things aren't working but I can't place blame there either. Any way to get the system back to the way it was and try Apache that way?

SVN works fine with apache when I restore it back to 1.4.4.

I know its preferable to not muck with the system installed versions. But xcode links directly to the dynamic libraries in /usr/lib so the only way to work with xcode is to replace. See.
http://blindgenius.wordpress.com/2009/03/22/subversion-16-xcode-312-versions/
http://stackoverflow.com/questions/1292190/installing-updated-svn-1-6-on-mac-os-x-to-integrate-with-xcode
http://www.lemonteam.com/blog/2008/12/setting-up-subversion-15-on-xcode/
Problem is the examples above are not os x server and using older versions of OS and SVN

I have gone back and forth a few times. Could it be something different in OS X server? Maybe something is not getting unloaded in Apache, so apachectl -t is not using the new modules, just using module code from a cache?. I did restart the server at least once after making the changes just in case but still get the error.

Maybe just changing the path in /etc/profile isn't good enough but need to change it in /etc/path?
Maybe I need to also replace the svn binaries in /usr/bin.

To be thorough I replaced the svn binaries in /usr/lib and flushed all the caches on the server and rebooted. Still get the dyld: Symbol not found: _apr_socket_sendfile error. This tells me that some other module besides your opt/subversion/lib/svn-apache/mod_dav_svn.so /opt/subversion/lib/svn-apache/mod_authz_svn.so is referencing the symbol. This maybe the difference between the OS X server and client versions.

I restored to the originals and everything works fine.

Is there some way to find out which module is referencing the symbol? Like changing the verbosity of the apache log or something?

Would it be possible to rebuild the binary with _apr_socket_sendfile symbol defined?

I confirmed that it must be another module that is referencing _apr_socket_sendfile because I commented out the loading of the two svn modules with svn 1.66 installed and it still gave me the error

So I guess there is no response on this? I reverted back to 1.4.4. for now.

Samuel,
I'm sorry but you've mucked with your environment enough for it to be many things. The Subversion binary I maintain is known to work on Leopard without issue if you follow the instructions. I'm not sure what else to suggest other than to get Subversion 1.6.6 installed, as the installer installs it, and follow the directions above exactly. You've done many things that are not discussed above and at least one of them has altered your results.

Take care,

Jeremy

Jeremy,
How goes it with Snow Leopard?
I tried it with no luck, My experience:

envvars as shipped from Apple
httpd: Syntax error on line 103 of /private/etc/apache2/httpd.conf: Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: dlopen(/opt/subversion/lib/svn-apache/mod_dav_svn.so, 10): Library not loaded: /opt/subversion/lib/libaprutil-1.0.dylib\n Referenced from: /opt/subversion/lib/svn-apache/mod_dav_svn.so\n Reason: Incompatible library version: mod_dav_svn.so requires version 4.0.0 or later, but libaprutil-1.0.dylib provides version 3.0.0

envvars with added /opt/subversion/lib
yld: Symbol not found: _apr_socket_sendfile
Referenced from: /usr/sbin/httpd
Expected in: /opt/subversion/lib/libapr-1.0.dylib
/usr/sbin/apachectl: line 81: 77829 Trace/BPT trap $HTTPD $ARGV

envvars commented out:
httpd: Syntax error on line 103 of /private/etc/apache2/httpd.conf: Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: dlopen(/opt/subversion/lib/svn-apache/mod_dav_svn.so, 10): Symbol not found: _dav_do_find_liveprop\n Referenced from: /opt/subversion/lib/svn-apache/mod_dav_svn.so\n Expected in: flat namespace\n

What I've got in my files currently
---- start httpd.conf addition----
#SubVersioN
# Load Subversion Apache Modules
LoadModule dav_svn_module /opt/subversion/lib/svn-apache/mod_dav_svn.so

# Work around authz and SVNListParentPath issue
RedirectMatch ^(/repos/svn)$ $1/

# Enable Subversion logging
CustomLog logs/svn_logfile "%t %u %{SVN-ACTION}e" env=SVN-ACTION

# Enable Subversion
DAV svn

# Directory containing all repository for this path
SVNParentPath /opt/repos/svn

# List repositories collection
SVNListParentPath On

#end SubVersioN
---- end httpd.conf addition ----
---- start /etc/envvars ----
#The following two lines commented out to get SubVersion source control to work correctly
#DYLD_LIBRARY_PATH="/usr/lib:$DYLD_LIBRARY_PATH"
#export DYLD_LIBRARY_PATH
---- end /etc/envvars ----

Well, you've given me an error that is more helpful than what I've found myself. For some reason, it appears mod_dav_svn.so is looking for an apr-util version that is older than expected but that shouldn't be possible. I'm still working on this.

I'm guessing 3 days is a bit short for your development cycle to have fixed the issue?
Seriously though, if you need any more info from my system or want me to test a change, I'll be glad to.

Hello Jeremy,

I've been experiencing the same problem as Scott and I might have found a potential solution or at least some potential help in figuring out the problem?

I had the socket sendfile error until I commented out the the two lines in envvars at which point I received errors similar to Ben back in June.

Then I got:
httpd: Syntax error on line 162 of /private/etc/apache2/httpd.conf: Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: dlopen(/opt/subversion/lib/svn-apache/mod_dav_svn.so, 10): Symbol not found: _dav_do_find_liveprop\n Referenced from: /opt/subversion/lib/svn-apache/mod_dav_svn.so\n Expected in: flat namespace\n

After reading through forums one led me to enable mod_dav.so and mod_dav_fs.so (which were disabled by default) and apache is starting and running after that. That might be something worth investigating.

Have you tested it with OS X Leopard Server. There are some notable differences between Leopard Server and Leopard. I believe Apple has some custom apache modules on Leopard Server that they don't have on Leopard.

Also the mucking I did was to allow xcode to work. This works just fine on Leopard so once again it may be a Leopard Server issue.

Hi Jeremy;

I'm really glad that I stumbled upon this post, however I too ran into some issues with Snow Leopard. I have it kinda working but something is a bit off.

First I am using Subversion 1.6.5, and I had to load the apache version of the mod_dav_svn.so.

My only issue now seems to be that if I use http://localhost/repos/svn I get "Unable to load..." and a bunch of seg faults in my apache log. If I use the local ip address, http://192.168.0.2/repos/svn, it seems to work fine.

Would you have any insight into this issue?

Thanks,
Russ

It would be nice if this installer included a launchdaemon plist file. I've googled all over and so far I don't see much consensus on how to get svnserve to launch at system startup for OS X Server. I've seen short files and very long files. I realize the repo folder location will have to be edited, but it would be nice to have what you considered a proper template for one.

(p.s. also not fond of the /opt location. /usr/local would have been more idiomatic.)

-- gw

A launchd plist would be a cool idea. The only issue with just giving you one is unless you created your repositories where the plist was configured, the plist wouldn't work. I could include a plist that could be used so that you could change the repositories location and then it would just work. What do you think?

As for /opt, there's a reason for it. Every other Subversion client in the world uses /usr/local. SCPlugin is a great example. Me using /usr/local would mean you couldn't install any other Subversion client that used /usr/local so no cli binary from me and SCPlugin installed at the same time. Even worse, the fact that I've been including ALL dependencies means any applications you used that had those deps would also be jeopardy. By standard Unix locations, /opt is for optional software and Subversion applies. I'm not sure why the location matters anyways. I document this heavily.

For everyone having the '_apr_socket_sendfile' problem, I found a solution, simply run:

sudo install_name_tool -change /usr/lib/libapr-1.0.dylib /usr/lib/libapr-1.0.2.7.dylib /usr/sbin/httpd

Which fixed the problem for me.

@jeremy : From what I've seen as examples so far, there's a number of details for an svn launchd plist that I've never seen used anywhere else, so a launchd plist as an example would be sufficient--users can edit paths. The example could go in an /extras folder or something, and clearly identified as a template. That's good enough. No need for a plist installer IMO.

As for /usr/local -- /opt may be "standard Unix" but it is not "standard OS X." Everything else I've installed from source or even binaries puts them in /usr/local. As an OS X user, that's where I expect stuff to be. The only thing I have ever seen use /opt is MacPorts (which I don't use because of all the duplication). I don't understand why you're expecting collisions when you can use /usr/local/collabnet_svn_1.6.x as a root location and symlink to /usr/local/collabnet_svn (or something) which wouldn't clash with anything else. MySQL, Rumpus, ImageMagick and any number of *nix apps install this way. I have several versions of MySQL installed this way for compatibility testing. It doesn't have to be /usr/local/subversion (and shouldn't be IMO, it should be more specific as to which distro, etc). All the deps would be organized in sub-dirs indentical to how you have them now. Anyway, I'm no *nix guru, maybe I'm still missing something.

Thank you so much for this article it's been really useful.
I too suffered the libaprutil-1.0.dylib and the _apr_socket_sendfile errors on a G4 mac mini with leopard 10.5.6 and svn 1.6.6. I upgraded to 10.5.8 to see if it made any difference and it didn't. Commenting out the envvars lines was the only way to get apache to load or so I thought.
Checking the error log confirmed that apache doesn't have permissions to create a log at /usr/logs/svn_logfile (which is the path your httpd snippet uses). I switched this location to match the path of the other apache log files '/private/var/log/apache2/svn_log' and it all started working beautifully.

I've never used OS X server but this chap (http://www.gridshore.nl/2008/12/21/upgrade-subversion-client-on-mac-osx/comment-page-1/#comment-27542) reckons users need to make a change in ServerAdmin to get the subversion binaries to work.

'Solved it… obvious I suppose but you also need to update the path of dav_svn_module in ServerAdmin to point to the new module that comes with subversion install default at /opt/subversion/lib/svn-apache/mod_dav_svn.so
Assuming you are using OS X Leopard Server.'

Best of luck!

Jack, there is a problem with Snow Leopard's Apache modules. I'm fixing them when we release the next Subversion binary (1.6.8) by no longer building one binary for all supported OS version and instead building a binary for each OS based on OS-supplied libs.

Greg, I will put an example launchd plist for svnserve in the next binary release.

This note is for those of us experiencing the "symbol not found" error as pertaining to mod_dav_svn.so (the gory details found in /var/log/system.log or /var/log/apache2/error.log)

The following guide at http://agileshrugged.com/blog/?p=14 has the solution: WebDav is disabled by default on Leopard & Snow Leopard AFAIK. To solve this in the GUI from the Dock:

1) load Server Admin
2) click on the arrow next to the entry bearing your server name in the left hand menu to expand the enabled services
3) select Web
4) select Sites in top menu (between Settings and Graphs)
5) select Options in the sub menu (between General and Realms)
6) check the WebDav box
7) restart your server

Keep in mind, this is for Snow Leopard (10.6.2) so the menus may be laid out differently in Leopard (10.5.X)

Phew!