Crash when starting in Mountain Lion
GoogleCodeExporter opened this issue · comments
What steps will reproduce the problem?
1. Upgrade OS X to Mountain Lion
2. Disable Gatekeeper (due to missing developer certificate)
3. Try to run svnX
What is the expected output? What do you see instead?
svnX crashes.
What version of the product are you using? On what operating system?
svnX 1.3.3, OS X 10.8 Mountain Lion
Please provide any additional information below.
Dyld Error Message:
Library not loaded: /usr/lib/libpq.5.dylib
Referenced from: /opt/subversion/lib/libsvn_client-1.0.dylib
Reason: no suitable image found. Did find:
/usr/lib/libpq.5.dylib: mach-o, but wrong architecture
So, svnX (i386, ppc) uses libsvn_client (i386, x86_64), which uses libpq
(x86_64).
This looks like the upgrade to Mountain Lion removed i386 support for libpq.
Could you provide x86_64 binaries for svnX? As far as I understand, this should
solve the issue.
If you see another feasible soultion, I would ha happy to know.
Original issue reported on code.google.com by ag...@posteo.de on 27 Jul 2012 at 9:47
I don’t have OS X 10.8.
Many people are/have been using svnX on OS X 10.8 successfully.
[I was led to believe that you can enable unsigned applications by simply
right-clicking them & selecting ‘Open’.
No need to disable Gatekreeper.]
According to Google libpq is part of PostgreSQL. None of my copies of
Subversion link against this,
so you must be using some 3rd party extension (or something).
The simple workaround for now would seem to be to disable the ‘Call
Subversion libraries directly’ preference.
You can do this without launching svnX by entering the following in
Terminal.app:
defaults write com.lachoseinteractive.svnX useOldParsingMethod -bool YES
However, this will impact the performance of svnX as it will have to run the
svn CLI and parse its output.
Alternatively you could try replacing your copy of libpq with the one from
10.7.x
or you could try building your own or obtain a 32/64-bit version from somewhere
else.
Or you could `lipo -remove i386` the libsvn_client as it’s broken without
compatible dependencies.
(But this, too, will also disable ‘Call Subversion libraries directly’
implicitly.)
A future release of svnX will, most likely, include 64-bit support.
However, that is unlikely to be a 1.x release.
Original comment by chris...@gmail.com on 27 Jul 2012 at 3:18
Thanks a lot for the quick reply and the hints. You can indeed right-click,
select "open" and then confirm that you know what you do.
I use the svn 1.7.5 binaries from
http://www.wandisco.com/subversion/download#osx since these seem to be the most
recent ones that are freely available. I have no idea why they require libpq,
since it should be vanilla Apache svn.
The workaround does not work - svnX still crashes rightaway with the same
message. I verified the setting by calling efaults read
com.lachoseinteractive.svnX useOldParsingMethod, which returned 1.
Removing i386 support from libsvn_client leads to another crash when running
svnX:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
I will just wait for wandisco to release a binary compiled against 10.8 and
report here what happens. Maybe they provide a workaround themselves. In the
meantime, I can just use the command line tools, since they run in 64bit mode,
which still works.
Original comment by ag...@posteo.de on 27 Jul 2012 at 7:44
My mistake.
SvnX weak links against various Subversion libraries via symbolic links in its
bundle.
If the libs/symbols are available it then tests the Subversion lib versions for
compatibility.
However, its missing an explicit test for a libsvn_client symbol (instead
assuming it must be valid if the others are).
Unfortunately, in this case, it appears to be the only invalid lib/symbol.
The workaround is simply to delete one of the symbolic links to one of the
other libs:
rm <path-to-your-svnX.app>/Contents/Frameworks/libapr.dylib
That will prevent it calling into any of Subversion’s libs & disable ‘Call
Subversion libraries directly’.
[Of course you wouldn’t be able to do that had the application been signed.
:-)]
I looked at the libsvn_client in Subversion-1.7.5_10.7.x.pkg from WANdisco
(that they claim is a “vanilla” Subversion 1.7.5).
It does indeed link against libpq.
I have 1.7.4 that I built from source (from Apache’s repo).
It does NOT link against libpq.
There is NO reference to libpq anywhere in the source.
(Nor in the Subversion 1.7.5 makefile or configure script.)
So, hopefully, it should be easy for WANdisco to fix it (as it appears to be
their problem).
Original comment by chris...@gmail.com on 28 Jul 2012 at 1:56
After removing the symbolic link, it worked. For some reason I also had to
delete the one to libsvn_client before svnX started, but that seems to be a
feasible workaround for now.
Thanks again - especially for looking into the WANdisco package as well!
Original comment by ag...@posteo.de on 28 Jul 2012 at 8:53
Unlinking libapr and libsvn_client fixed this issue for me. Thanks!
Original comment by kmark937 on 28 Jul 2012 at 9:51
Today, WANdisco provided an updated build, which seems to work so far.
I am just not sure whether svnX attempts to use libsvn_client again.
So far I restored the symlinks I deleted and disabled the useOldParsingMethod.
Is there any way I can verify which method svnX actually uses?
Thanks,
Andreas
Original comment by ag...@posteo.de on 9 Aug 2012 at 5:58
It’s probably easier/better to simply re-download svnX and restore it from
the disc image then try to recreate the symlinks.
If you open svnX’s preferences dialog then the ‘Call Subversion libraries
directly’ checkbox should be enabled (if it’s detected suitable libs) &
checked (if it’s using them).
Also you should be able to toggle that checkbox between doing refreshes of a
working copy window & notice a significant (~3 to 5 times) speed up when it is
checked. [Do several refreshes so as to prime the disc cache.]
Original comment by chris...@gmail.com on 9 Aug 2012 at 6:27
Thanks for the support and the workarounds.
Everything now works again with the new subversion build provided by WANdisco.
From my point of view, the issue can be closed.
Original comment by ag...@posteo.de on 9 Aug 2012 at 7:20
Issue 183 has been merged into this issue.
Original comment by chris...@gmail.com on 27 Aug 2012 at 6:09
For me the removal of the sym-links didn't solve the problem. I still get the
same error message.
I have installed the subversion libraries from the macports repository.
Original comment by funsh...@gmail.com on 28 Aug 2012 at 4:42
Fixed by installing updated Subversion libraries from WANdisco.
Original comment by chris...@gmail.com on 4 Sep 2012 at 5:14
- Changed state: Done
Issue 193 has been merged into this issue.
Original comment by chris...@gmail.com on 17 Jan 2013 at 12:41
[deleted comment]
Issue 205 has been merged into this issue.
Original comment by chris...@gmail.com on 21 May 2014 at 12:53