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.
Found: Link-time errors for native reference entry points for p/invoke
purposes when using the new unified iOS projects.
Steps to reproduce:
* Create an iOS classic project with a native reference to a known-good
static library added to the project. Add a DllImport-tagged external
function declaration to one of the known good entry points.
* Build the project and observe success.
* Create an identical iOS unified project with the same static library
added as a native reference, same entrypoint declaration.
* Build the project and observe failure.
Result: Failed references to the native entry point, e.g.
. . .
Tool /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/bin/mtouch execution started with arguments: --cache /Users/foo/Projects/PInvokeUnified/PInvokeUnified/obj/iPhone/Debug/mtouch-cache --dev /Users/foo/Projects/PInvokeUnified/PInvokeUnified/bin/iPhone/Debug/PInvokeUnified.app --executable PInvokeUnified --debug --linksdkonly --sdkroot /Applications/Xcode.app/Contents/Developer --sdk 8.1 --targetver 8.0 --abi=armv7 -r /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll -r /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Xml.dll -r /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Xamarin.iOS.dll -r /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll -r /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/mscorlib.dll /Users/foo/Projects/PInvokeUnified/PInvokeUnified/bin/iPhone/Debug//PInvokeUnified.exe
Xamarin.iOS 8.6.0 Indie Edition using framework: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk
Process exited with code 1, command:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -Wl,-pie -arch armv7 -miphoneos-version-min=8.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk /Users/foo/Projects/PInvokeUnified/PInvokeUnified/obj/iPhone/Debug/mtouch-cache/PInvokeUnified.exe.armv7.o /Users/foo/Projects/PInvokeUnified/PInvokeUnified/obj/iPhone/Debug/mtouch-cache/Xamarin.iOS.dll.armv7.o /Users/foo/Projects/PInvokeUnified/PInvokeUnified/obj/iPhone/Debug/mtouch-cache/mscorlib.dll.armv7.o /Users/foo/Projects/PInvokeUnified/PInvokeUnified/obj/iPhone/Debug/mtouch-cache/registrar.armv7.o /Users/foo/Projects/PInvokeUnified/PInvokeUnified/obj/iPhone/Debug/mtouch-cache/main.armv7.o -o /Users/foo/Projects/PInvokeUnified/PInvokeUnified/bin/iPhone/Debug/PInvokeUnified.app/PInvokeUnified -framework Foundation -framework CoreGraphics -framework UIKit -framework CFNetwork -lz -liconv -u _mono_pmip -u _LZ4_decompress_safe_offsets_limits -u _monotouch_timezone_get_data -u _monotouch_log -u _xamarin_release_managed_ref -u _xamarin_create_managed_ref -u _xamarin_get_block_descriptor /Library/Frameworks/Xamarin.iOS.framework/Versions/220.127.116.11/SDKs/MonoTouch.iphoneos.sdk/usr/lib/libmonosgen-2.0.a /Library/Frameworks/Xamarin.iOS.framework/Versions/18.104.22.168/SDKs/MonoTouch.iphoneos.sdk/usr/lib/libmonotouch-sgen-debug.a /Library/Frameworks/Xamarin.iOS.framework/Versions/22.214.171.124/SDKs/MonoTouch.iphoneos.sdk/usr/lib/libapp.a -dead_strip
Undefined symbols for architecture armv7:
"_LZ4_decompress_safe_offsets_limits", referenced from:
-u command line option
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
. . .
Expected: Identical outcomes and build success.
* I got burned by this after spending a couple hours to convert a complex project
* My original assumption is that this was an omission of arm64 in my native library,
but this did not turn out to be the case. Fails for even simple armv7 builds.
* Were there changes to native library support in Unified that require new
* I do not actually see my native-reference static library listed on the final link
line. Other objects, other frameworks, other libraries. The entry point is
specified with a "-u" option. But it doesn't look like the toolchain honors
Versions: (current alpha channel at the time of this submission)
Version 5.7 (build 646)
Mono 3.12.0 ((detached/dc0ce1d)
GTK+ 2.24.23 (Raleigh theme)
Package version: 312000066
Apple Developer Tools
Xcode 6.1.1 (6611)
Version: 126.96.36.199 (Indie Edition)
Build date: 2014-12-09 10:40:45-0500
I do not see any static library being provided in the mtouch arguments from the partial build log above (i.e. the only ones being linked are those that XI provides itself).
Where do you link that static library ?
Can you attach the samples (classic and unified) ?
or the full logs to both the classic (working) and unified (failing) builds ?
note: please add "-v -v -v -v" to the additional mtouch arguments so we can have every details.
(To your comments "I do not see any static library being provided..."):
I believe the very issue is that the new unified toolchain is not honoring native references in the first place---not emitting those in the command line for linking. This is a regression. Static libraries associated with the project (via the add->add native reference from the context menus) are a primary way to associate libraries to be linked. Furthermore, this is a common pattern by which adding for Xamarin Studio will supply libraries for custom build purposes. Whatever the root cause, this is probably a good opportunity for Xamarin to establish a new build validation test to ensure that these references are honored across any future changes.
Let me know if I can provide any additional info.
Thanks for the samples, it's clear the msbuild-based unified build does not give mtouch any informant about the native library.
XS builds for most* classic apps use the old, custom build system and do provides the right arguments to mtouch:
> --gcc_flags "\"-L/Users/poupou/Downloads/PInvokeUnified/PInvokeUnified\" \"-lBootstrapiOS\"
> -force_load \"/Users/poupou/Downloads/PInvokeUnified/PInvokeUnified/libBootstrapiOS.a\"
* except if the app uses some new iOS8 features
XS builds for unified uses an msbuild-based system. It looks like it does not support the "Native References" as those are not given to mtouch.
The workaround is to add the required (and missing) native linker flags to mtouch using the "Additional mtouch arguments" in the Project Options.
(..."adding for Xamarin Studio" in my last was supposed to be "addins for Xamarin Studio" --- thanks, autocorrect.)
Thanks for the confirmation, Sebastien.
The toolchain I employ uses some automation around the population of native references (via a custom addin) --- not sure if this can be updated for the workaround, but I'll give it a try. Otherwise, I'll hang on a little while longer in beta and hope this gets fixed before versions get pushed to beta and stable.
I appreciate the quick response.
I think the targets are using the wrong item name. It may be possible to fix this by editing Xamarin.iOS.Common.targets and changing the line
This local edit to the Xamarin.iOS framework did resolve the issue.
I'll just keep making the edit until a new version with a fix lands.
Thanks, and happy holidays.
Fixed in git master
I'd be happy to verify-fixed this when it hits alpha (where the bug originates), but it's not yet fixed there. (I keep having to make manual edits each time a new version lands.)
Still broken in Xamarin.iOS 188.8.131.52.
Still broken in Xamarin.iOS 184.108.40.206.
This fix is scheduled to be part of 8.10 (XI 8.8 being 8.6 + iOS 8.2/watchkit support).