Bug 22088 - MMPTASK: warning MM2006: Native library '<native>.dylib' was referenced but could not be found.
Summary: MMPTASK: warning MM2006: Native library '<native>.dylib' was referenced but ...
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: MSBuild ()
Version: 1.10.0
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: 1.12.0
Assignee: Chris Hamons
Depends on:
Reported: 2014-08-14 01:22 UTC by Brian Berry
Modified: 2015-01-22 09:39 UTC (History)
3 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 Brian Berry 2014-08-14 01:22:56 UTC
Found: With the new Xamarin.Mac build system ( and 
even current beta 1.10.x.x, as best I can tell), a warnings without
clear understanding on how to resolve it:

MMPTASK:  warning MM2006: Native library 'libBootstrap.OSX.dylib' was referenced but could not be found.

This library is built prior to the XS build of the OSX project via a custom process.
It was utilized fine in the prior version of the Xamarin.Mac toolchain.
What would be useful to know is where *exactly* it is looking to find this.
I have dropped it in all the usual places, played with the native references,
everything I could think of.  I have even injected it into the .app myself
and am still unable to run---either from the debugger or via manual launch.

The debug/launch issues may be something else entirely.  After all, MM2006 is only
a warning and the libs are being deployed one way or another.

On launch from the debugger, I get a modal popup that indicates
"The application has not been built." --- no further information.

A manual launch ('open BootstrapOSX.app' at its path):

LSOpenURLsWithRole() failed with error -10810 for the file /Users/. . ./bin/Debug/BootstrapOSX.app.

... and an ominous crash:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff91d56866 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff8f5a535c pthread_kill + 92
2   libsystem_c.dylib             	0x00007fff85afab1a abort + 125
3   com.your-company.Bootstrap.OSX	0x00000001000d73f3 mono_handle_native_sigsegv + 611
4   com.your-company.Bootstrap.OSX	0x0000000100055a27 mono_arch_handle_altstack_exception + 87 (exceptions-amd64.c:915)
5   com.your-company.Bootstrap.OSX	0x00000001000f0516 mono_sigsegv_signal_handler + 374 (mini.c:6876)
6   libsystem_platform.dylib      	0x00007fff90d885aa _sigtramp + 26
7   com.your-company.Bootstrap.OSX	0x000000010010ec54 mono_assembly_get_image + 4 (assembly.c:3217)
8   com.your-company.Bootstrap.OSX	0x000000010004da28 mono_jit_exec + 24 (driver.c:988)
9   com.your-company.Bootstrap.OSX	0x00000001000021a7 main + 1447
10  com.your-company.Bootstrap.OSX	0x00000001000011a4 start + 52

At your suggestion, I can file the launch issues separately, if you believe that they
are most likely unrelated to the MM2006 issue.  Just let me know.
Comment 1 Brian Berry 2014-08-14 12:41:47 UTC
Updated info this morning.

The .dylib warning does not appear to be related to the "The application has not been built." / crash issue.

The latter appears entirely related to the project name mangling (I can reproduce with none of our adding activated and a simple pair of brand new, nothing-changed projects from templates.

I will file the mangling/crash issue separately,

Still looking for info on how the new Xamarin.Mac build system is looking for .dylibs, so that I can adjust how we build to appease it.

Comment 2 Brian Berry 2014-08-14 13:03:59 UTC
(Note: the mangling issue is now filed as https://bugzilla.xamarin.com/show_bug.cgi?id=22116).
Comment 3 Chris Hamons 2014-08-15 12:58:04 UTC
A few questions:

- Is this a unified project or classic (Xamarin.Mac.dll or XamMac.dll)?
- Did it work in 1.8?
- exceptions-amd64.c suggests a native exception on launch (possibly not including that dylib. Is there anything else in the log?
- Can you package up a small sample application showing the problem?
Comment 4 Brian Berry 2014-08-15 13:18:14 UTC
Thanks for the reply, Chris.

Unified project.  This was while doing the conversion due to the Indie licensing restrictions.

This warning did not appear under classic, for the same custom .dylib build step etc., AFAIK.

Note that, per my comments above, the .dylib warning and the startup crashes are in fact unrelated.  The crashes are due to the name mangling issues filed under 22116.

On the warning issue itself:  It looks like the new Unified build is paying attention to the DllImport tags it sees and, based on those inferences, attempting to identify libraries it needs to build/package.   The issue in my case is that the library warned about is being built outside of the nominal build process as a custom build step.  It's actually a viable .dylib, and when placed in the app structure at the right location (<foo>.app/Contents/MonoBundle), the app sees it just fine and everything works.

So we're really talking about a warning.  X.Mac sees a need for a DLL, has some internal logic to satisfy that need by either building a .cproj, or finding a native reference, or ... other?   I am happy to mutate our custom build step to plop the .dylib we build ourselves (again, custom pre-build step) into a location that makes XS.Mac see it and silence the warning.  But the warning isn't telling me where it expects to find it, or if that is even possible.

Any insight appreciated!
Comment 5 Chris Hamons 2014-12-03 18:05:31 UTC
Nice to get in for 1.12 but might have to wait for 2.0.
Comment 6 Chris Hamons 2014-12-19 17:44:43 UTC
I've made two fixes to resolve this issue:

- c4e3330b553ed8bf082a62f4e96f94b5b5c5b399 / master - I've reduced the number of warnings by blacking listing some native libraries found on Linux that have unused dllimport in mscvrt.

- 817a0f79181ab80f80fc5c08e6f57b25d0a83403 / master - I've added a new option to mmp "ignore-native-library=" that lets you specific certain native libraries are not to be searched for and will be added in some additional processing that you do. If you specify your assembly with that, the warning should go away.

This may make 1.12 or if not will be in the release after that.
Comment 7 Brian Berry 2014-12-19 18:12:58 UTC
Thanks.  I'll give it a try when it lands.  Happy Holidays, Chris!
Comment 8 Chris Hamons 2014-12-19 18:42:30 UTC
Same to you!
Comment 9 Rajneesh Kumar 2015-01-22 09:39:54 UTC
I have checked this issue with the following builds:

Xamarin Studio:5.7.1 (build 14)
Installation UUID: ff0c16c6-3c75-46d8-ac56-56c3b56e2c76
Mono 3.12.0 ((detached/a813491)
GTK+ 2.24.23 (Raleigh theme)
Package version: 312000068
Apple Developer Tools Xcode 6.1.1 (6611)
Build 6A2008a
Xamarin.Mac : (Indie Edition)
=== Build Information ===
Release ID: 507010014
Git revision: a4dd61ad7f8b3695be4b17bcb5c3ae6b81438cf7
Build date: 2015-01-19 15:21:09-05
Xamarin addins: 081208fe3bbf40e24a562867c6c7fba20a9b94b6
=== Operating System ===
Mac OS X 10.10.1
Darwin Apples-iMac.local 14.0.0 Darwin Kernel Version 14.0.0
Fri Sep 19 00:26:44 PDT 2014
root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64

I create a Unified API template project and and observed that user is able to build and run successfully without any warning or error. Here is the screencast for the same: Screencast: http://www.screencast.com/t/vNvXGE9U

This issue has been fixed, hence closing this issue.