Error: Failure while executing: /Library/Developer/CommandLineTools/usr/bin/otool -L /usr/bin/install_name_tool

[evantill]

brew seems broken on OS X 10.11.3 after removing Xcode and installing CLT using xcode-select install

Bug reports:

To recover some space on my HDD I removed Xcode and Reinstalled the CLT.
After that brew complains:

Error: Failure while executing: /Library/Developer/CommandLineTools/usr/bin/otool -L /usr/bin/install_name_tool

In fact, install_name_tool is now in /Library/Developer/CommandLineTools/usr/bin/install_name_tool

my brew config and brew doctor output are in the following gist : https://gist.github.com/evantill/f2ec66a037b9efb7db7b

[evantill]

trying to rerun xcode-select --installresult in an error xcode-select: error: command line tools are already installed, use "Software Update" to install updates

[MikeMcQuaid]

I don't have Xcode installed either; you should still have a /usr/bin/install_name_tool.

[MikeMcQuaid]

Did you manually remove it?

[evantill]

I have added brew doctor -dto the gist https://gist.github.com/evantill/f2ec66a037b9efb7db7b

[evantill]

I manually removed it following http://osxdaily.com/2012/02/20/uninstall-xcode/ (article updated on 12/17/2015).

But install_name_tool exist not in /usr/bin but in /Library/Developer/CommandLineTools/usr/bin/

[evantill]

The problem seems located in check_for_bad_install_name_tool which is using a hard coded path /usr/bin/install_name_tool.

As a counterexample see OS.Mac.install_name_tool which is using /usr/bin/xcrun to locate install_name_toolpath.

Hope this help.

[evantill]

What can I do to help to solve this issue ?

[evantill]

@MikeMcQuaid do you consider this issue as a bug or not ?

[MikeMcQuaid]

@evantill I don't consider it an issue considering a system file has been removed but we'd accept a pull request to fix the hard coded versions considering there's an existing inconsistency. Could you try and open a pull request? This should help and I'm happy to walk you through anything else: https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/How-To-Open-a-Homebrew-Pull-Request-(and-get-it-merged).md#how-to-open-a-homebrew-pull-request-and-get-it-merged

Thanks!

[evantill]

Ok, I fixed the hardcoded version. But the check_for_bad_install_name_tool will check the dynamically linked libraries. It expect /usr/lib/libxcselect.dylibbut in my system install_name_toolis linked to /usr/lib/libSystem.B.dylib

I never installed osx-gcc-installer nor RailsInstaller.

Not sure how to proceed now.

[evantill]

I checked on an other Mac (fresh install with Command Line Tools installed from the UI) and I found two install_name_tool

machine:~ user$ otool -L  /usr/bin/install_name_tool
/usr/bin/install_name_tool:
    /usr/lib/libxcselect.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

machine:~ user$  otool -L  /Library/Developer/CommandLineTools/usr/bin/install_name_tool
/Library/Developer/CommandLineTools/usr/bin/install_name_tool:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)

[MikeMcQuaid]

@evantill You may want to fix it so it handles your case too as it seems that there's different linkage depending on the install location.

[UniqMartin]

Just to hopefully make things clearer: The different linkage of those tools, depending on whether they are in /usr/bin or in $(xcode-select -p)/usr/bin is intentional and there's nothing wrong about that. The former are wrappers that redirect to the actual tool by asking xcode-select for the path where the actual tools are (and suggests to install the Command Line Tools if those haven't been set up yet). Makes sense?

[evantill]

@UniqMartin are you sure that /usr/bin/install_name_tool is a wrapper to the active developer directory and that it should always exist or is it an assumption ?

[UniqMartin]

@evantill I was already pretty sure, but I nevertheless checked on a bare installation of OS X 10.11.3 (neither Command Line Tools nor Xcode installed). There is a long list of binaries in /usr/bin that link against /usr/lib/libxcselect.dylib, among them install_name_tool, otool, and a few other prominent ones. Almost all of them are wrappers that dispatch to the respective tool in the active developer directory (or result in a popup that suggests to install the Command Line Tools, if unavailable); if those are not wrappers, it would be very strange why almost all of them are about 18 KB in size. (I'm relatively sure it has been like that since OS X 10.9, but currently don't have a system where I can verify this quickly.)

I'm not even entirely sure how you managed to delete /usr/bin/install_name_tool as that should have been protected by SIP (System Integrity Protection) introduced in OS X 10.11.

[evantill]

thank you for the clarifications. SIP has been desactivated on my Mac to fix some issues with homebrew after upgrading to OS X El Capitan.

I think that we can close this issue.

[MikeMcQuaid]

@evantill I'd advise you re-enable it; it's a security feature and from Homebrew's perspective it stops you breaking system things we rely on.