Bug 19473 - Error: MT5210 Native linking failed against C++ library
Summary: Error: MT5210 Native linking failed against C++ library
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: 7.2.1
Hardware: Macintosh Mac OS
: High normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2014-05-01 18:52 UTC by Dan Belcher
Modified: 2014-05-05 17:28 UTC (History)
6 users (show)

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

Demo project with failed linking - includes library (4.23 MB, application/zip)
2014-05-01 18:52 UTC, Dan Belcher

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 Dan Belcher 2014-05-01 18:52:38 UTC
Created attachment 6704 [details]
Demo project with failed linking - includes library

As outlined in the following forum post:
my project fails to link against a C++ library.  Before updating to Xamarin.iOS, this was working as expected.

At the request of @SebastienPouliot, attached is a simplified test case using the library in question.
Comment 1 Ram Chandra 2014-05-02 03:26:59 UTC
I tried this issue and I am able to reproduce this issue:

Steps to reproduce:
1 Open the attached project in XS
2 Build the project

I observed that when I deploy the "attached project" in following build I am able to deploy the project successfully.

Mac OS X 10.9.2
Xamarin Studio: 4.2.3 (build 60)
Build Information
Release ID: 402030060
Git revision: 30c4afc300c2a39ec5300851357ce02e49dd217e
Build date: 2014-03-05 22:09:33+0000
Xamarin addins: f8a9589b57c2bfab2ccd73c880e7ad81e3ecf044

I have checked the same project with latest build and I am getting almost 575 errors i.e. "Native linking failed". I have found that both project have same mtouch argument i.e.

"cxx -gcc_flags "-L${SolutionDir}/rhinocommon/c/build/Release-ios/ -lopennurbs -force_load ${SolutionDir}/rhinocommon/c/build/Release-ios/libopennurbs.a"

Screencast (With stable): http://screencast.com/t/AYbgCI1l
Screencast (With latest build):  http://www.screencast.com/t/5tgvp2v3C63

Build output log: https://gist.github.com/saurabh360/591ec5de56ce0dbafbce

Regression: This sample is working fine with stable (Xamarin.iOS: )

Environment Info:

Mac OS X 10.9.2
Xamarin Studio: 5.0 (build 784)
Build Information
Release ID: 500000784
Git revision: ea367c9e829e7c627ec8927e8832df6a74390d61
Build date: 2014-04-29 09:48:53-04
Xamarin addins: 92dcfc8532a8c6d21783289c176417d7c17bf492
Comment 2 Sebastien Pouliot 2014-05-02 09:06:28 UTC
@Ram thanks for confirming.

A few things:

1. when you compare two versions of XI (for regression) then you need to include build logs for *both*;

2. gist has a content size limit. When using it you need to check that what you pasted is complete (it's not). If gist can't handle the log (then end will be truncated) then please attach the logs (to the bug report) as text files.
Comment 3 Ram Chandra 2014-05-02 09:56:07 UTC
@Sebastien, thanks for the suggestions. Here are the build logs:

Build logs (Xamarin.iOS:  :https://gist.github.com/anonymous/d946cce6b1ea6fd69a95
Build logs (Xamarin.iOS:  : https://www.dropbox.com/s/tzjvqrnmwalmyna/BugLogs_19473.rtf
Comment 4 Sebastien Pouliot 2014-05-02 10:04:51 UTC
@Ram, the first one is not the *build* log, it's the application (execution) output. Can you attach that build log ? (it's the one I don't have)
Comment 5 Ram Chandra 2014-05-02 10:22:37 UTC
Build logs (Xamarin.iOS: : https://www.dropbox.com/s/9nhc6j1gvb32o0c/BugLogs1.rtf
Comment 6 Sebastien Pouliot 2014-05-02 10:43:48 UTC
@Ram thanks! That confirm my suspicion about all those "-u XXX" in the newer build log.
Comment 7 Sebastien Pouliot 2014-05-03 14:52:25 UTC
It's a regression (and a rather old one) from ef16b557f5d797c4b793ff5342e3143c1b57ffe0 (c.c. Rolf)
Comment 8 Rolf Bjarne Kvinge [MSFT] 2014-05-05 05:01:14 UTC
This occurs because there are P/Invoke declarations to native methods that don't exist (in the third-party native library). In the latest Xamarin.iOS version (7.2.1) we ask the native linker to not remove native methods referenced by P/Invokes (but this has the side effect that the application won't link if there are P/Invokes to native methods that don't exist).

There are a few ways around this:

* Remove the P/Invokes in question from your source code.
* Enable the managed linker for all assemblies (this is done in the project's iOS Build options, by setting "Linker Behavior" to "All assemblies"). This will effectively remove all the P/Invokes you don't use from the app (automatically, instead of manually like the previous point). The downside is that this will make your simulator builds somewhat slower, and it may break your app if it's using reflection - more information about the linker can be found here: http://docs.xamarin.com/guides/ios/advanced_topics/linker/)
* Create a second native library which contains the missing native symbols. Note that this is merely a workaround (if you happen to try to call those functions, your app will crash). Here is an example of how this can be done: https://gist.github.com/rolfbjarne/0fe4136a600a42eddda3
Comment 9 Rolf Bjarne Kvinge [MSFT] 2014-05-05 05:56:30 UTC
I've added a new error message which will explain the issue a little better.
Comment 10 Dan Belcher 2014-05-05 10:47:45 UTC
@Rolf: Thank you for the clear explanation and for generating the gist for the workaround...this definitely helps.