Bug 33912 - Command line tools not installed on El Capitan
Summary: Command line tools not installed on El Capitan
Alias: None
Product: Runtime
Classification: Mono
Component: packaging ()
Version: unspecified
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Alexis Christoforides
Depends on:
Reported: 2015-09-12 22:21 UTC by MPH
Modified: 2015-11-03 20:49 UTC (History)
9 users (show)

Is this bug a regression?: ---
Last known good build:

Console messages from mono installation. (12.80 KB, text/plain)
2015-09-29 19:44 UTC, Iritscen

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description MPH 2015-09-12 22:21:22 UTC
In previous releases, the mono command line tools would be installed.  However, when Xamarin is installed on El Capitan (Mac OS X 10.11), the command line tools do not appear to have been installed.
Comment 1 Iritscen 2015-09-29 19:43:57 UTC
Adding more detail in case it is needed. As far as I am aware, Mono's installation is totally broken in 10.11, so I am surprised if this bug is really not fixed yet.

10.11 introduces System Integrity Protection, which prevents the installer from placing mono's binaries in /usr/bin/.  When installing, the following messages (see attached) are printed to the system log.  This occurs with the latest alpha release,
Comment 2 Iritscen 2015-09-29 19:44:47 UTC
Created attachment 13135 [details]
Console messages from mono installation.
Comment 3 Iritscen 2015-10-04 09:38:40 UTC
The previous issue was in fact fixed by, as the soft links to Mono's binaries are now being placed in /usr/local/bin/, not /usr/bin/, which is guarded by 10.11's SIP feature.

The new issue is that, when /usr/local/bin/ has never been created on the machine, the script silently fails in its attempt to place soft links there. This is a problem because virgin OS X installs do not have this directory, let alone /usr/local/.
Comment 4 dw_whittlesey 2015-10-04 11:21:53 UTC
'The fix is to extend the search path for dynamic libraries to include the prefix where mono is installed. Which is not usually on the dynamic linker path.' Would someone please be kind enough to explain in detail how to do this for someone not well versed in Mac operations? Thank you!
Comment 5 Iritscen 2015-10-04 16:54:48 UTC
Hi there. You seem to be quoting the release notes for The developers are simply saying that this fix for the search paths was made in that release. They also had to change the installation directory from /usr/bin/ to /usr/local/bin/ with a previous update.

With those changes made, Mono should work in El Capitan, as long as /usr/local/bin/ exists before you try to install Mono. Creating that path manually will fix the problem I am reporting. You can do this by entering "sudo mkdir /usr/local/bin" in Terminal and supplying the root password when asked for it (this is probably your user password if you are using the first user account created on the system; if you did not make a password for your account yet, then you need to do that first or 'sudo' commands will not work).
Comment 6 dw_whittlesey 2015-10-04 23:04:18 UTC
How do I uninstall the software that was installed by running the .pkg file (prior to creating /usr/local/bin/? If the "fix for the search paths" was created in the and a previous release(?) why is it still necessary to manually create a directory to enable mono to run? My interest in mono is limited to being able to use Keepass 2.30 on my Macbook Pro. Thanks
Comment 7 Iritscen 2015-10-05 10:58:03 UTC
You actually don't need to uninstall Mono. You can simply run the .pkg again after creating /usr/local/bin/.

The actual Mono files are in /Library/Frameworks/Mono.framework, but some programs do not attempt to find Mono here, instead relying on the command line to tell it where Mono is. The command line only knows where Mono is as long as it is installed in one of the command line's search paths, like /usr/bin/ or /usr/local/. So the Mono installer .pkg, after installing Mono.framework, creates soft links in /usr/local/bin/ to the various Mono programs in that framework.

It's the creation of those soft links that is currently hampered when the /usr/local/bin/ directory does not already exist. But if you create it, then run the Mono .pkg again, it will simply write the framework over top of the one that's already there, which does no harm, then at the end it will attempt again to create the soft links to the framework, except it will succeed this time.

Two alternate, less technical solutions are waiting for someone to fix this in Mono, and waiting for someone to fix this in Keepass, which could be updated by the developers to look for Mono in /Library/Frameworks/.
Comment 8 dw_whittlesey 2015-10-05 22:38:17 UTC
I've created the /usr/local/bin directory and rerun the mono .pkg installation. I then opened a terminal and typed mono /Applications/KeePass-2.30/KeePass.exe and pressed enter. -bash: Mono: command not found 
I've also tried /Library/Frameworks/Mono.framework/Mono /Applications/KeePass-2.30/KeePass.exe with -bash: /Library/Frameworks/Mono.framework/Mono: cannot execute binary file being the result.
Also /usr/local/bin/mono /Applications/KeePass-2.30/KeePass.exe xxxx.kdbx
-bash: /usr/local/bin/mono: No such file or directory
Before the upgrade to El Capitan Mono /Applications/KeePass-2.30/KeePass.exe xxxx.kdbx worked without fail.
Of course the fact that the Download "buttons" at http://www.mono-project/download/ are reversed (i.e. Download Mono MDK (El Capitan Preview) points to and Download Mono MDK points to doesn't increase the likelihood of a successful installation (of mono)and operation of KeePass-2.30!
Once that issue was discovered, I downloaded and ran the correct version and other than a little path confusion finding my xxxx.kdbx file to correct KeePass 2.30 opens and runs beautifully. Thanks the help! 

"The only absolute in the world of technology is that it doesn't work when you need it!" whizm Dawit aka itech@dw-net.net
Comment 9 Iritscen 2015-10-06 09:07:44 UTC
Glad it's working. Yes, you wanted the Mono MDK, not the El Capitan preview. That's another issue I neglected to mention: although the El Capitan preview is actually for a later version of Mono, 4.2.0, that .pkg was produced before the MDK .pkg, back when they were still trying to install Mono to /usr/bin/, which simply won't work.

Your usage of mono on the command line also had some issues, but it's not necessary to get into that since KeePass is working for you now :-) We shouldn't really have been discussing tech support here at all, so thanks to the Xamarin Team for putting up with us.
Comment 10 dw_whittlesey 2015-10-07 11:46:11 UTC
"We shouldn't really have been discussing tech support here at all, so thanks to
the Xamarin Team for putting up with us." Yes, indeed thanks! Then again, if not here, where?
Comment 11 Alexis Christoforides 2015-11-03 17:09:25 UTC
Hello! We've fixed our symlinks issue in our latest packages of both the 4.0 and 4.2 series. They are now consistently installed in /usr/local/bin.
Comment 12 Iritscen 2015-11-03 20:49:57 UTC
Hi Alexis. Has this additional issue been handled, from comment #3 above?:

"The new issue is that, when /usr/local/bin/ has never been created on the
machine, the script silently fails in its attempt to place soft links there.
This is a problem because virgin OS X installs do not have this directory, let
alone /usr/local/."