You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
LSOpenURLsWithRole() failed for the application /Users/moeffju/Library/Application Support/GitX/GitX 0.14.89/GitX.app with error -10810 for the file /Users/moeffju/src/repo.
Welp, checked the build phase and the framework should still be copied. Betting @rowanj is doing something a little more custom, so probably only he can solve this one.
I'd say gitx is a binary, not a package/.app, and thus @rpath (which tells dyld to go look in Contents/Resources/) doesn't makes sense. It's a side-effect of the move to Objective-Git as the backend of GitX.
What's the output of otool -L /usr/local/bin/gitx ? Mine says :
% otool -L /usr/local/bin/gitx
/usr/local/bin/gitx:
@executable_path/../Frameworks/ObjectiveGit.framework/Versions/A/ObjectiveGit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1187.37.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.18.0)
/System/Library/Frameworks/ScriptingBridge.framework/Versions/A/ScriptingBridge (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 945.16.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
and the culprit ought to be the first one.
You could try to fix it by doing something like install_name_tool -change @rpath/ObjectiveGit.framework/ObjectiveGit @executable_path/../Frameworks/ObjectiveGit.framework/Versions/A/ObjectiveGit but I'm not sure it will work... It doesn't work with longer paths.
This is a breaking change to functionality that has been existent in GitX since 0.3 back in 2008 (and likely back to 0.1 and alpha versions previous to 0.1) from the original GitX project by @pieter; per the README:
GitX itself is fairly simple. Most of its power is in the 'gitx' binary, which you should install through the menu. the 'gitx' binary supports most of git rev-list's arguments. For example, you can run gitx --all to display all branches in the repository, or gitx -- Documentation to only show commits relating to the 'Documentation' subdirectory. With gitx -Shaha, gitx will only show commits that contain the word 'haha'. Similarly, with gitx v0.2.1.., you will get a list of all commits since version 0.2.1.
I frequently open GitX from within a repository directory at the CLI by simply running gitx, and I oft use gitx -S<string> to expedite searches from the CLI; these are core features of the application, and always have been.
Of course we can monkey-patch around the issue, but ultimately this is something that should be mended without requiring users to run install_name_tool or create aliases in bash configuration file(s).
Wait.. are we all talking about the same thing? I'm not talking about the "gitx" binary at all. When I open GitX.app, it crashes instantly, after updating to this morning's update.
Builds between 0.14.86 and 0.14.92 don't launch (Library not found) - please grab the latest or previous build manually; since it won't run as far as the auto-update.
Activity
moeffju commentedon Jul 3, 2013
Console also says:
(Mac OS 10.9 DP 2, btw)
sdegutis commentedon Jul 3, 2013
Same for me, can't find ObjectiveGit. Betting it was accidentally removed from the copy-frameworks build phase.
woodwardjd commentedon Jul 3, 2013
commenting to a) follow just this bug and b) to say "thanks for jumping on this so quickly" :)
sdegutis commentedon Jul 3, 2013
Welp, checked the build phase and the framework should still be copied. Betting @rowanj is doing something a little more custom, so probably only he can solve this one.
tiennou commentedon Jul 3, 2013
I'd say
gitx
is a binary, not a package/.app
, and thus@rpath
(which tellsdyld
to go look inContents/Resources/
) doesn't makes sense. It's a side-effect of the move to Objective-Git as the backend of GitX.What's the output of
otool -L /usr/local/bin/gitx
? Mine says :and the culprit ought to be the first one.
You could try to fix it by doing something like
install_name_tool -change @rpath/ObjectiveGit.framework/ObjectiveGit @executable_path/../Frameworks/ObjectiveGit.framework/Versions/A/ObjectiveGit
but I'm not sure it will work... It doesn't work with longer paths.moeffju commentedon Jul 3, 2013
I use
git x
, an alias which calls GitX.app viaopen -a
.tiennou commentedon Jul 3, 2013
This one works :
install_name_tool -add_rpath @loader_path/../Frameworks /usr/local/bin/gitx
.@moeffju You're running 10.9, and I'm not ;-). I'm trying to find what error -10810 is, but
gitx
works with the command above.Edit: found a better way ;-).
tiennou commentedon Jul 3, 2013
@moeffju Here's something : http://www.finetunedmac.com/forums/ubbthreads.php?ubb=showflat&Number=25369. Does that ring a bell ?
schwa commentedon Jul 3, 2013
Broken for me too. @moeffju's "git x" is a great idea. (And yes running 10.9)
@tiennou's install_name_tool fix is a good workaround. Thanks!
digitaljhelms commentedon Jul 3, 2013
+1
This is a breaking change to functionality that has been existent in GitX since 0.3 back in 2008 (and likely back to 0.1 and alpha versions previous to 0.1) from the original GitX project by @pieter; per the README:
I frequently open GitX from within a repository directory at the CLI by simply running
gitx
, and I oft usegitx -S<string>
to expedite searches from the CLI; these are core features of the application, and always have been.Of course we can monkey-patch around the issue, but ultimately this is something that should be mended without requiring users to run
install_name_tool
or create aliases in bash configuration file(s).I'll be staying at 0.14.86 for now...
sdegutis commentedon Jul 3, 2013
Wait.. are we all talking about the same thing? I'm not talking about the "gitx" binary at all. When I open GitX.app, it crashes instantly, after updating to this morning's update.
digitaljhelms commentedon Jul 3, 2013
@Evanescence you may be experiencing #208, this issue is specific to running
gitx
from the CLI.sdegutis commentedon Jul 3, 2013
Ah, yes. My mistake. Apologies all around.
simple10 commentedon Jul 3, 2013
@tiennou's solution worked for me
install_name_tool -add_rpath @loader_path/../Frameworks /usr/local/bin/gitx
I was getting this error:
rowanj commentedon Jul 4, 2013
I was up 'till 2 this morning fixing this, not sure where it snuck in; but the 'Library not loaded' crash should be fixed in 0.14.92
http://builds.phere.net/GitX/development/GitX-dev-92.dmg
If that has other issues, you can find 0.14.86 (the previous working build) on the new GitHub releases page:
https://github.com/rowanj/gitx/releases
rowanj commentedon Jul 4, 2013
gitx
command line tool still has this problem (which I'll track as command line broke after last release of gitx #210)Add fixes for #207, #208, #210 to the change log
rowanj commentedon Jul 8, 2013
Should be fixed in 0.14.95 (current auto-update version, also available from the website and GitHub page).
You may need to re-install the command line tools.
GitX 0.14.95 (download .dmg)
digitaljhelms commentedon Jul 8, 2013
👍 fix confirmed on my end, ta muchly!
rowanj commentedon Jul 8, 2013
Thanks for confirming that, @digitaljhelms - closing this issue.