Subversion 1.6, XCode 3.1.2 & Versions

22 03 2009

I saw recently that Subversion has been updated to Version 1.6.

I decided to take the plunge and install it. lo and behold, it broke both XCode and Versions 😦

After reading the error descriptions of which there were a few from Xcode and Versions, it seems that the Collabnet installer DOES NOT update the symlinks in the /usr/lib folder to point at the new libraries it just installed 😦

so off to the terminal we go ……

cd /usr/lib

sudo rm libap*-1.dylib
sudo rm libsvn*-1.dylib
sudo rm libap*-1.0.dylib
sudo rm libsvn*-1.0.dylib

sudo ln -s /opt/subversion/lib/*-1.0.dylib .
sudo ln -s /opt/subversion/lib/*-1.dylib .

this should fix both Versions and XCode to work with the new Libraries.

Happy Versioning

EDIT: I have not encountered any problems so far but its early days yet 😉




12 responses

26 03 2009
Quinn Taylor

Just a note to other readers, this will patch the dynamic libraries to the new versions, but not the binary tools in /usr/bin, as was done in the earlier post for SVN 1.5.4.

My question is whether this causes any problems with Apache. I’ve heard that tinkering with the APR library can make Apache 2.x unhappy, probably when trying to use host SVN repositories on the same machine. If anyone has solved the problem, is it something simple like a library compatibility conflict with mod_dav_svn, or a larger part of Apache? I’d love to upgrade my built-in SVN tools to 1.5.x or even 1.6, but don’t want to break Apache in the process.

27 03 2009

As I don’t use apache for my access back to my local reps (ssh on a different port) I cant say whether this is an issue or not


27 03 2009

A quick update on the first part of your reply…..
The binaries, libs, man, from previous updates are backed up (assuming you used the installer of course) to the /opt folder. So if you have problems you can go back if you need to.
The libs changed version number (and filename), hence the broken links and yes the actual binaries did not change name so their links remained unbroken.

Thanks for noting my discrepancies Quinn

27 03 2009
Quinn Taylor

To partially answer my own question, people using Apache to host SVN repositories will also need to make sure Apache links to the correct versions of and — you can find some details at this post:

27 03 2009
Quinn Taylor

No worries, I don’t figure everyone does. I just wanted to put out a word of warning for those who do, to avoid getting bitten and taking their server offline.

27 03 2009
Quinn Taylor

Well, the CollabNet installer backs up any previous SVN versions installed in /opt/subversion, but it probably wouldn’t be clear to many users that the middle few lines delete several symlinks in in /usr/lib and replaces those symlinks with ones pointing to the counterparts in /opt/subversion/lib, without touching either the built-in or newly-installed dynamic libraries.

This approach will work in most instances, but does create some confusion in /usr/lib that, while it is undoable, is not immediately obvious. Also, it can cause problems for anything that links against the modified symlinks if the new version is not binary compatible. (This is what happens with in Apache2, for those hosting SVN repositories via HTTP.)

The CollabNet installer intentionally avoids mucking about with users’ symlinks so that using the new version is strictly opt-in. Users can specify which version of svn they want, or put /opt/subversion/bin at the front of their $PATH. That doesn’t help Xcode since it links against the libraries, but that’s a known symptom of the CollabNet installer, not an oversight.

It’s very likely that these problems will go away (at least for a while) when Snow Leopard ships … I’m optimistic that it will include a newer version of SVN as the default. 🙂

27 03 2009

Aah thanks Quinn I see your point 😉

in any case My previous post about 1.5.4 makes a backup of all the libs and binaries that would be changed , I forget where I found those instructions now, these (if from a virgin install or a non updated/relinked one at least) should be the original svn V1.4 files installed with Leopard.

so for new users upgrading its probably better to err on the side of caution and use the 1.5.4 method so you can go back if there is a problem.


5 06 2009

So – for us users who followed your instructions and removed all those links – how can we best back to a world where both svn and apache work?

Thanks in advance for any advice…

7 06 2009

Ok I found out how to get the standard OS X install to work again.
as a start to verify the issues are the same as the ones i came across
open the terminal and enter

sudo apachectl -k start

this SHOULD (it did for me) produce some error similar to
dyld: Symbol not found: _apr_socket_sendfile
and the name of the library apache was looking in for the symbol most likely

Right. so if thats the case then all you should have to do is delete the symlink libapr-1.0.dylib
like so
cd /usr/lib
sudo rm libapr-1.0.dylib

and then link back to the original library

sudo ln -s ./libapr- ./libapr-1.0.dylib

for good measure i also did the same for the libaprutil-1.0.dylib library too

Apache can then be tested by entering
sudo apachectl -k start

if all is well you should just be returned to the prompt with no errors.

I did have to do an extra step as this did not work for me and i still recieved the sendfile error, further investigation with an
ls -la libap*
showed that the libapr- and the libaprutil- files had exactly the same file sizes as the version files respectively.

so as I had another virgin intel imac handy i copied the files from there which did have different file sizes to the ones I had.
after copying them in and changing the owner for them back to root I again tried to start the apache server.
This time all was good.
to further test this i started the webserver in the system prefs->sharing and clicked the link for my machines ip and it brought up the default “If you are seeing this page” apache msg which I was REALLY happy about.


6 06 2009

Apologies if my instructions broke Apache for you 😦
As I dont use apache at all only clients and commandline access for subversion it was unintentional.

Please see the fix above for further info

12 11 2009

You can also use;

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

to have httpd use the appropriate lib.

17 11 2009
Looking Glass » Security Updates, Xcode & Subversion

[…] quick search – and I found two other folks reported the same thing (Paul Solt and Blind Genius).  I’ll restate the solution here, but effectively Xcode is dynamically linking with the […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: