Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
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, 22.214.171.124.
Created attachment 13135 [details]
Console messages from mono installation.
The previous issue was in fact fixed by 126.96.36.199, 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/.
'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!
Hi there. You seem to be quoting the release notes for 188.8.131.52. 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).
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 184.108.40.206 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
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/.
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 220.127.116.11 and Download Mono MDK points to 18.104.22.168) 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 email@example.com
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 22.214.171.124 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.
"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?
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.
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