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
Developer Community or GitHub 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.
Reported on behalf of a user.
> System.DllNotFoundException: libc.dylib
> at at (wrapper managed-to-native) MonoMac.ObjCRuntime.Class:mprotect (intptr,int,int)
## Steps to reproduce
Compile and run a Xamarin.Mac project with linking turned off, but with signing with a "Mac Developer" provisioning profile enabled:
1. Create a new Xamarin.Mac project.
2. Set the project to the "Debug" configuration.
3. Under "Project Options -> Mac OS X Packaging", change the Identity to "Mac Developer (Automatic)", or pick a "Mac Developer: ..." Identity that has a provisioning profile.
4. Build and run the project.
The app fails because `libc.dylib` cannot be located.
a) This is not the intended behavior, and warrants a bug fix.
b) This is the correct behavior. In that case, maybe a warning could be added to the "Mac OS X Packaging" pane. If not, no worries. This bug report will hopefully help users quickly identify the problem in the future.
## Additional result
Re-signing the app without the "keychain-access-groups" entitlement avoids the problem, but this changes the app's keychain permissions.
To test this:
1. Remove the "keychain-access-groups" entry from the generated `MyApp.xcent` entitlements file.
2. Re-sign the app with the modified entitlements:
> codesign -fs "Mac Developer: ..." --entitlements MyApp.xcent MyApp.app/
3. Run the app.
1. Under "Project Options -> Mac OS X Packaging -> General [tab] -> Linker Behavior", select "Link Framework SDKs only" or "Link all".
2. Add "-r /usr/lib/libc.dylib" to "Advanced Mono Bundling Options -> Extra Arguments". This will copy libc.dylib into the App bundle.
3. Enable "Include the Mono runtime in the application bundle". Then after building, manually edit the `MyApp.app/Contents/MonoBundle/config` file. Replace the line...
> <dllmap dll="libc" target="libc.dylib" os="!windows"/>
> <dllmap dll="libc" target="/usr/lib/libc.dylib" os="!windows"/>
## Version information
Mac OS X 10.8.5
Weird, it looks like the path to load the .dylib does not include /usr/lib
That's likely a launcher issue (not mmp) since it does not involve the linker (which mmp handle and fix the issue) and signing is done by the XS addin.
> 2. Add "-r /usr/lib/libc.dylib" to "Advanced Mono Bundling Options -> Extra
> Arguments". This will copy libc.dylib into the App bundle.
Please don't do (or suggest) that :-) You're copying a system library into an app which is likely illegal* and can cause weird issues at runtime (e.g. you supply a ML libc in a Mavericks computer).
* copyrights (system libraries are generally not redistributable)
I can duplicate and this happens even without using `mmp` (e.g. if the Mono runtime is not included in the app bundle then `mmp` is not called) when the app is signed.
Pretty sure it's because the signed apps are being run inside a sandbox (and the library path is not fully qualified).
Fixed in master / db1fa645354ed297548a3ce7f9c2073349462ce1
The best workaround until this is released is to use (1) "Link SDK" (unless the app makes this impossible to use) or (3) which removes the ambiguity.
Note that from the OS perspective* there's no point in signing an app that depends on (potentially) unsigned third party code, like Mono. IOW "Include the Mono runtime in the application bundle" should be enabled for code signing to make sense since it "works" only if the app is self-contained and use trusted (e.g. OS) services
* OTOH, from the developer's perspective, it might be useful when debugging some issues - so removing the option could be harmful.
Very nice extra information, discussion, and quick fix! Many thanks!