[Mono-osx] Potential missing symlink creation issue for 2.6.4_3

Gregory Smith wolfy at treellama.org
Fri Apr 30 13:41:30 EDT 2010

On Fri, 30 Apr 2010, Michael Hutchinson wrote:

> On Fri, Apr 30, 2010 at 12:20 PM, Jacob Page <jpage at fender.com> wrote:
>> We may have uncovered an issue with the installation of Mono 2.6.4_3 on OS
>> X.  We recently did a public beta release, and part of our application’s
>> install process is to install Mono.  However, after everything was
>> installed, our application failed to launch on the users’ computers.  Our
>> application launch script executes our main assembly by running
>> /usr/bin/mono with the assembly as a command-line argument.  On a clean
>> install of 2.6.4_3, we found that /usr/bin/mono symbolic link was no-longer
>> generated.  I guess running it worked for us because something else
>> established that link (MonoDevelop?  Older versions of the framework?).
>> Is using the /usr/bin/mono link even the “right way” to launch Mono-based
>> applications?  If so, I guess this is a bug report.  If not, what is the
>> recommended practice?  Directly invoking
>> /Library/Frameworks/Mono.framework/Commands/mono, or is there a file type
>> association for .exe files?
> The symlink should work, but I'd recommend explicitly invoking
> /Library/Frameworks/Mono.framework/Versions/Current/bin/mono, or even
> a specific version, so that you can guarantee which Mono you're
> running with. We've seen problems where a user would install Mono from
> Macports, which would be in the path, and would lack expected
> libraries or have other problems.

macpack uses `which mono` which seems to me like it wouldn't work if 
/usr/bin/mono weren't present.

> You can find a more robust launch script and more explanations here:
> http://mjhutchinson.com/journal/2010/01/24/creating_mac_app_bundle_for_gtk_app

Seems like a lot of this would be useful to have in macpack? I see it sets 
DYLD_FALLBACK_LIBRARY_PATH, which might fix the aforementioned 
System.DllNotFoundException: libgtk-quartz-2.0.0.dylib problem that has 
been in the last couple releases. Since I use stock macpack, I've had to 
tell users to go back to 2.4.3.

Still, it would be nice to have a deprecation notice before breaking stuff 
like this.


More information about the Mono-osx mailing list