Bug 16250 - Signing with Entitlements, but without linking causes "System.DllNotFoundException: libc.dylib"
Summary: Signing with Entitlements, but without linking causes "System.DllNotFoundExce...
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: Other ()
Version: 1.6.19
Hardware: PC Mac OS
: --- minor
Target Milestone: ---
Assignee: Aaron Bockover [MSFT]
Depends on:
Reported: 2013-11-14 22:48 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2013-11-15 11:03 UTC (History)
2 users (show)

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

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 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.

Related Links:

Description Brendan Zagaeski (Xamarin Team, assistant) 2013-11-14 22:48:17 UTC
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.

## Result

The app fails because `libc.dylib` cannot be located.

Perhaps either:
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.
> <key>keychain-access-groups</key>
> <array>
> 	<string>DEVID.com.my-company.MyApp</string>
> </array>

2. Re-sign the app with the modified entitlements:
> codesign -fs "Mac Developer: ..." --entitlements MyApp.xcent MyApp.app/

3. Run the app.

## Workarounds

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
Xamarin.Mac: 1.6.19
Mac OS X 10.8.5
Comment 1 Sebastien Pouliot 2013-11-15 08:59:38 UTC
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)
Comment 2 Sebastien Pouliot 2013-11-15 10:15:42 UTC
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).
Comment 3 Sebastien Pouliot 2013-11-15 10:38:40 UTC
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.
Comment 4 Brendan Zagaeski (Xamarin Team, assistant) 2013-11-15 11:03:34 UTC
Very nice extra information, discussion, and quick fix! Many thanks!