Bug 39100

Summary: [Mono alpha / OSX] 'library not loaded' error when using embedded mono
Product: [Mono] Installers Reporter: RichardW <numpsyuk>
Component: GeneralAssignee: Alexis Christoforides <lexas>
Severity: major CC: alkpli, miguel, mono-bugs+mono, pancake
Priority: High    
Version: 4.4.0 (C7)   
Target Milestone: ---   
Hardware: Macintosh   
OS: Mac OS   
Tags: Is this bug a regression?: Yes
Last known good build: 4.2.2

Description RichardW 2016-02-24 17:28:24 UTC
I have an OSX/ObjectiveC project that uses embedded mono to call some .NET assemblies from a native app.

Using the alpha, the app builds ok, but on run fails with:

dyld: Library not loaded: /private/tmp/source-mono-4.3.2/bockbuild-xamarin/profiles/mono-mac-xamarin/package-root/lib/libmonosgen-2.0.1.dylib

This works ok with the previous 4.2.2 build, and also with a local (64bit) build of the master branch.
Comment 1 Rodrigo Kumpera 2016-04-14 01:05:56 UTC
Does it work with 4.4?

Can you provide any form testing instructions or a patch to fix the issue?
Comment 2 RichardW 2016-04-15 12:02:26 UTC
Using the 4.4.0 beta release, I get a failure to load


I can get this by simply creating a new ObjC command line app in Xcode, adding mono.framework to the project, and trying to run it.

The issue seems to be that the library install name on libmonosgen is set to the path above, so linked apps try to load it from there (hence it not being found).
When I build mono locally using make, the install name gets set to a path under the prefix directory I specify during configuration, so it actually seems like more of an issue with bockbuild rather than mono itself?

I've worked around the problem in my app for now by having a post build step that uses install_name_tool to reset the link to libmonosgen-2.0.1.dylib to /Library/Frameworks/Mono.framework/Libraries/libmonosgen-2.0.1.dylib. I can also get the same effect by running install_name_tool against libmonosgen-2.0.1.dylib itself, to set the path to the install dir of the lib.

I don;t think this should be necessary though - shouldn't the libs installed by the installer package have the names set to an appropriate place to start with?

Hope this makes sense - i'm still getting to grips with how this stuff works on OS X myself, while trying to port some Windows apps.
Comment 3 Rodrigo Kumpera 2016-04-15 20:33:48 UTC
We got a similar report internally, so I think I know what the issue is.

Alexis, this looks to be the same stating issue that jonp is having.
Comment 4 pancake 2016-05-30 14:27:47 UTC
I can reproduce this issue, i have workaround it with those commands. but its clearly an issue in the SDK.

sudo mkdir -p /private/tmp/source-mono-4.4.0/bockbuild-mono-4.4.0-branch/profiles/mono-mac-xamarin/package-root/lib/
sudo cp /Library/Frameworks/Mono.framework/Versions/Current/lib/libmonosgen-2.0.dylib /private/tmp/source-mono-4.4.0/bockbuild-mono-4.4.0-branch/profiles/mono-mac-xamarin/package-root/lib/libmonosgen-2.0.1.dylib
Comment 5 RichardW 2016-06-17 10:07:47 UTC
I worked around the issue by having a post build step that did

install_name_tool -change /private/tmp/source-mono-4.4.0/bockbuild-mono-4.4.0-branch/profiles/mono-mac-xamarin/package-root/lib/libmonosgen-2.0.1.dylib /Library/Frameworks/Mono.framework/Libraries/libmonosgen-2.0.1.dylib

on my app, and that worked ok until the final 4.4.0 release started trying to load the lib from </private/tmp/source-mono-4.4.0-c7-baseline/bockbuild-mono-4.4.0-c7-baseline/profiles/mono-mac-xamarin/package-root/lib/libmonosgen-2.0.1.dylib>

Another possibility is to run install_name_tool against the installed libmonosgen-2.0.1.dylib so that things linked against it look in the correct place (means changing mono itself, but only on systems used for builds).
Comment 6 Alexander Köplinger [MSFT] 2016-08-17 16:15:17 UTC
This was fixed with C7SR0 and https://github.com/xamarin/bockbuild/commit/5bdf018a305302964c1f9f1b3969af8cac65605a.