Let's say that you are using a beta version of a new operating system that you can't name because it is covered by a non-disclosure agreement, and you have also installed the newest version of its development tools, which are also covered by NDA, and when you try to run the
git svn command, you get this output:
dyld: lazy symbol binding failed: Symbol not found: _Perl_Gthr_key_ptr Referenced from: /usr/../Library/Perl/5.12/darwin-thread-multi-2level/auto/SVN/_Core/_Core.bundle Expected in: flat namespace dyld: Symbol not found: _Perl_Gthr_key_ptr Referenced from: /usr/../Library/Perl/5.12/darwin-thread-multi-2level/auto/SVN/_Core/_Core.bundle Expected in: flat namespace error: git-svn died of signal 5
Apparently, the problem is that
git-svn is implemented in Perl, and there is something wrong with the Perl configuration used when you run
What do you do?
It turns out you can fix this by putting the Git executables provided by the new development tools at the head of your PATH, by executing this command (or adding it to
XXXXX.app is the unnamed development tool.
Alternatively, you can add all the command-line tools to your PATH like this:
Credit to Vandad Nahavandipoor for the hint.
Another option would be to use the xcrun utility to run
git. You can do this:
xcrun git svn blah-blah-blah
or put this into your
.bashrc so that you don't have to remember to type
alias git='xcrun git'
If you are the kind of person who thinks its a good idea to replace system files with symlinks, you might try symlinking
/Applications/XXXXX.app/Contents/Developer/usr/libexec/git-core/git. However, that alone doesn't work, because Git will still run the
git-svn executable from its default location,
/Library/Developer/CommandLineTools/usr/libexec/git-core, and you will still have the
_Perl_Gthr_key_ptr problem. So you also need to symlink the default location to
/Applications/XXXXX.app/Contents/Developer/usr/libexec/git-core/, or set the
GIT_EXEC_PATH environment variable.