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 😉
Blind Genius's Weblog 
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.
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
Sorry
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
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 mod_dav_svn.so and mod_authz_svn.so — you can find some details at this post: http://www.thoughtspark.org/node/19
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.
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 mod_dav_svn.so 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. 🙂
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.
HTH
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…
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
libapr-1.0.dylib
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-1.0.2.7.dylib ./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-1.0.2.7.dylib and the libaprutil-1.0.2.7.dylib files had exactly the same file sizes as the 1.0.2.12 version files respectively.
so as I had another virgin intel imac handy i copied the 1.0.2.7 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.
HTH
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
You can also use;
install_name_tool -change /usr/lib/libapr-1.0.dylib /usr/lib/libapr-1.0.2.7.dylib /usr/sbin/httpd
to have httpd use the appropriate lib.
[…] 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 […]