Closed juwens closed 2 years ago
I'm seeing something similar in the latest release:
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CertDuplicateCertificateContext. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CertFreeCertificateContext. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CertGetCertificateContextProperty. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CryptDecodeObject. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CryptEncodeObject. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CryptFindOIDInfo. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CryptMsgClose. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CryptMsgGetParam. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CryptMsgOpenToDecode. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CryptMsgOpenToEncode. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _CryptMsgUpdate. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _FormatMessageW. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _GetProcessHeap. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _HeapAlloc. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5210: Native linking failed, undefined symbol: _HeapFree. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
MTOUCH : error MT5201: Native linking failed. Please review the build log and the user flags provided to gcc: -ObjC -ObjC -ObjC -lc++ -lz -ObjC -ObjC -ObjC -lc++ -lz [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
clang : error : linker command failed with exit code 1 (use -v to see invocation) [/Users/ank/dev/ca/criticalarc/Source/Applications/iOS/OmniGuard/OmniGuard.csproj]
28 Warning(s)
17 Error(s)
Interestingly, these all seem to the Win32 API's. Very strange to see this when targetting Xam.iOS.
With Visual Studio for Mac 8.9.x we see the same native linking problems. Funny thing is that building for the iOS simulator works, but not for iOS device.
With Visual Studio for Mac 8.8.x, these native linking problems are not present.
One mac has VS for Mac 8.9.x and the other one has VS for mac 8.8.x and the same version of Xcode 12.4
With Visual Studio for Mac 8.9.x we see the same native linking problems. Funny thing is that building for the iOS simulator works, but not for iOS device.
With Visual Studio for Mac 8.8.x, these native linking problems are not present.
One mac has VS for Mac 8.9.x and the other one has VS for mac 8.8.x and the same version of Xcode 12.4
Definitely. The difference is: the Simulator is x86_64, a real iPhone is ARM64
Turns out a reference to the System.Security.Cryptography.Pkcs
package via MailKit
/MimeKit
was causing the issue. Even though the package supports netstandard
targetting, somehow the net46
TFM version was being copied to the output directory.
I think this wasn't a problem before because we weren't actually calling code in this assembly from iOS, but a recent change in Xamarin.iOS where it preserves PInvoke links seems to leave the references in there and they make it to the native linker, which it doesn't like.
So I've just moved this package reference to another project in the solution to work around the issue.
Same issue here...
We have also this issue!
I'm trying to create a minimal example.
I've inspected the resulting "exe" file with AvaloniaILSpy and found a reference to mscorlib (which looks like a windows mscorlib) in the iOS App. The reference does not exist in our project, so the compiler/linker seems to add it.
csc uses this mscorlib
/reference:/Users/jjaehrig/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/mscorlib.dll
the iOS mono mscorlib 2.0.5.0 /Library/Frameworks/Xamarin.iOS.framework/Versions/14.14.2.5/lib/mono/Xamarin.iOS/mscorlib.dll
is then copied to obj folder ...App.iOS/obj/iPhone/Release/mtouch-cache/1-Link/mscorlib.dll
then, still the "mono mscorlib 2.0.5.0" is copied from step 2-PreBuild to step 3-Build
Copied /Users/jjaehrig/repo/MyProject/src/FoobarApp/FoobarApp.iOS/obj/iPhone/Release/mtouch-cache/2-PreBuild/mscorlib.dll to /Users/jjaehrig/repo/MyProject/src/FoobarApp/FoobarApp.iOS/obj/iPhone/Release/mtouch-cache/3-Build/mscorlib.dll
Further down the rabbithole:
Could not resolve the module reference System in mscorlib.dll
Linking with the framework CoreFoundation because it's referenced by a module reference in mscorlib.dll
Linking with the framework Security because it's referenced by a module reference in mscorlib.dll
...
Building mscorlib.dll from mscorlib.dll
...
Target(s) /Users/jjaehrig/repo/MyProject/src/FoobarApp/FoobarApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/mscorlib.aotdata.arm64, /Users/jjaehrig/repo/MyProject/src/FoobarApp/FoobarApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/mscorlib.dll.s must be rebuilt.
...
MONO_PATH=/Users/jjaehrig/repo/MyProject/src/FoobarApp/FoobarApp.iOS/obj/iPhone/Release/mtouch-cache/3-Build /Library/Frameworks/Xamarin.iOS.framework/Versions/14.14.2.5/bin/arm64-darwin-mono-sgen --debug -O=gsharedvt -O=-float32 --aot=mtriple=arm64-ios,data-outfile=/Users/jjaehrig/repo/MyProject/src/FoobarApp/FoobarApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/mscorlib.aotdata.arm64,static,asmonly,direct-icalls,full,nodebug,dwarfdebug,direct-pinvoke,msym-dir=/Users/jjaehrig/repo/MyProject/src/FoobarApp/FoobarApp.iOS/obj/iPhone/Release/mtouch-cache/3-Build/Msym,outfile=/Users/jjaehrig/repo/MyProject/src/FoobarApp/FoobarApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/mscorlib.dll.s /Users/jjaehrig/repo/MyProject/src/FoobarApp/FoobarApp.iOS/obj/iPhone/Release/mtouch-cache/3-Build/mscorlib.dll
...
Generating static registrar for mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e
...
Target(s) /Users/jjaehrig/repo/MyProject/src/FoobarApp/FoobarApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/mscorlib.dll.o must be rebuilt.
...
mtouch references /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/mscorlib.dll
Target _CompileToNative:
/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/bin/mtouch @/Users/jjaehrig/repo/MyProject/src/FooApp/FooApp.iOS/obj/iPhone/Release/response-file.rsp --nowarn:109 -v -v -v -v
Provided arguments:
@/Users/jjaehrig/repo/MyProject/src/FooApp/FooApp.iOS/obj/iPhone/Release/response-file.rsp
Provided arguments:
--sgen-conc
'/target-framework:Xamarin.iOS,Version=v1.0
--http-message-handler=NSUrlSessionHandler
--i18n=west
--cache=/Users/jjaehrig/repo/MyProject/src/FooApp/FooApp.iOS/obj/iPhone/Release/mtouch-cache
--root-assembly=/Users/jjaehrig/repo/MyProject/src/FooApp/FooApp.iOS/bin/iPhone/Release/FooApp.iOS.exe
--sdkroot=/Applications/Xcode.app/Contents/Developer
--targetver=9.0
--dev=/Users/jjaehrig/repo/MyProject/src/FooApp/FooApp.iOS/bin/iPhone/Release/FooApp.iOS.app
--executable=FooApp.iOS
--nolink
--sdk=14.4
--aot-options=-O=-float32
--abi=arm64
--symbollist=/Users/jjaehrig/repo/MyProject/src/FooApp/FooApp.iOS/obj/iPhone/Release/mtouch-symbols.list
--dsym=no
--reference=/Users/jjaehrig/repo/MyProject/src/Lib/Common.Abstractions/bin/Release/netstandard2.0/Common.Abstractions.dll
--reference=/Users/jjaehrig/repo/MyProject/src/FooApp/FooApp/bin/Release/netstandard2.0/FooApp.dll
--reference=/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/mscorlib.dll
--reference=/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/OpenTK-1.0.dll
--reference=/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll
--reference=/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll
--reference=/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Facades/System.Drawing.Common.dll
--reference=/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Xml.dll
--reference=/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Xamarin.iOS.dll
--reference=/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Facades/Microsoft.Win32.Primitives.dll
--reference=/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Facades/Microsoft.Win32.Registry.AccessControl.dll
--reference=/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Facades/Microsoft.Win32.Registry.dll
--reference=/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Facades/netstandard.dll
In the build log the correct Xamarin.ios mscorlib is referenced.
Loaded assembly 'System.IO.FileSystem, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' from /Library/Frameworks/Xamarin.iOS.framework/Versions/14.14.2.5/lib/mono/Xamarin.iOS/Facades/System.IO.FileSystem.dll
References: 'mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'
AvaloniaILSpy | VS Mac 14.14 |
---|---|
Found this in the build output. Is this of any significance?
Could not resolve the module reference System in mscorlib.dll
But then directly after the Could not resolve
:
Linking with the framework CoreFoundation because it's referenced by a module reference in mscorlib.dll
Linking with the framework Security because it's referenced by a module reference in mscorlib.dll
I've found a workaround.
By adding -v -v -v -v
to MtouchExtraArgs to your app.ios.csproj.
<PropertyGroup>
<MtouchExtraArgs>-v -v -v -v</MtouchExtraArgs>
</PropertyGroup>
"_EvilMethod", referenced from:
blocks.wrapper_managed_to_native.... in System.Security.AccessControl.dll.o
System.Security.AccessControl.dll.o
"_AdjustTokenPrivileges", referenced from:
wrapper_managed_to_native_Interop_mincore_AdjustTokenPrivileges_Microsoft_Win32_SafeHandles_SafeTokenHandle_bool_Interop_mincore_TOKEN_PRIVILEGE__uint_Interop_mincore_TOKEN_PRIVILEGE__uint_ in System.Security.AccessControl.dll.o
Without the trailing *.o
from System.Security.AccessControl.dll.o
<MtouchExtraArgs>--dlsym:System.Security.AccessControl.dll</MtouchExtraArgs>
<MtouchExtraArgs>--dlsym:System.Security.AccessControl.dll --dlsym:System.Security.Principal.Windows.dll --dlsym:System.IO.FileSystem.AccessControl.dll</MtouchExtraArgs>
<MtouchExtraArgs>$(MtouchExtraArgs) --dlsym:System.Security.AccessControl.dll</MtouchExtraArgs>
<MtouchExtraArgs>$(MtouchExtraArgs) --dlsym:System.Security.Principal.Windows.dll</MtouchExtraArgs>
<MtouchExtraArgs>$(MtouchExtraArgs) --dlsym:System.IO.FileSystem.AccessControl.dll</MtouchExtraArgs>
But there is a regression in Xamarin.ios, because it worked fine before. Without this workaround.
But there is a regression in Xamarin.ios, because it worked fine before. Without this workaround.
I think you are right. Visual Studio for Mac 8.8.x works fine, while Visual studio for Mac 8.9.x (i don't remember the version we have on the Build machine) - freaks out with these native linker issues. The Xcode version is the same: 12.4. I suspect it to be something something in the msbuild process, together with some NuGet packages.
In the release notes of 14.14 I've found this suspicious candidate for the regression #10182 [dotnet] Prevent linking out code referenced by P/Invoke
@filipnavara and @rolfbjarne do you think this might be caused by #10182 ?
@filipnavara and @rolfbjarne do you think this might be caused by #10182 ?
Highly unlikely, that's a code that should affect .NET 6 only.
Confirmed on my side, will raise it to see if we do find the culprit and do a release.
https://github.com/xamarin/Xamarin.Forms/issues/14054, Is this a similar issue? I am also having the same issue
@juwens can you provide us with a sample that worked and a Xamarin.iOS version that you have used with that sample? It might be the case that this never worked and is a regression in the dependencies and not on our side.
this seems to be a regression, ever since we updated my team had the same linking problem, same offending dlls
System.Security.AccessControl.dll.o System.Security.Principal.Windows.dll.o System.IO.FileSystem.AccessControl.dll.o
@keozx that does not point to a regression in our product. If the project does reference nugets that are not correct, we will throw an error and although we might look like the culprit, we are not.
Without a project that worked fine in a previous version and does not work in the current one, there is not much information to work with. We need a project in order to be able to help.
@mandel-macaque I understand that you may need a minimal project, but your statement "It might be the case that this never worked" doesn't make any sense, we are several people facing the same problem and you stated before:
Confirmed on my side, will raise it to see if we do find the culprit and do a release.
and later you removed the breaking-change label, why?
@keozx I believe @mandel-macaque meant to say that it could be a regression outside of Xamarin and in the NuGets or how they were resolved. It does sound suspiciously like it's picking up some code that is meant to be Windows only or picking the .NET Framework version of code from the NuGets instead of a cross-platform .NET Standard one.
Yeah I'll try to identify which one, for example the windows one is somehow an implicit dependency, from what I see in nuget is used by this https://www.nuget.org/packages/System.Net.Security/ which we explicitly reference, so I'll try to dig more but in theory a project referencing that nuget should reproduce it, not sure
For things like System.Net.Security there should be an implementation coming from Mono/Xamarin runtime pack that should override the NuGet. There was a bug that caused this mechanism to fail and that was fixed quite recently (https://github.com/xamarin/xamarin-macios/pull/10928). If some dependency pulled in the NuGet it could have incorrectly overridden the framework assembly.
@filipnavara you expressed it better than I did. @kdubau the pkg with the fix for #10928 on stable can be found here: https://github.com/xamarin/xamarin-macios/commit/05b928072d3b2c2e4192c4034784da4674000e0c#commitcomment-48685544 and will be present in the next SR.
Please @mandel-macaque help on issue https://github.com/xamarin/xamarin-macios/issues/11066 We are waiting to deploy a new iOS release and we couldn't. Thanks
@JORGEGO replied in the issue. But is the same problem as reported here.
@juwens's workaround saved me. At first I could not get the necessary information from build log. After I set "MSBuild project build output verbosity" to "Diagnostic", I got all the information. (Tools -> Options -> Projects and Solutions -> Build and Run)
My result was: --dlsym:System.Security.Principal.Windows.dll --dlsym:Microsoft.Win32.Registry.dll
I've found a workaround.
1. Enable verbose mtouch build
By adding
-v -v -v -v
to MtouchExtraArgs to your app.ios.csproj.<PropertyGroup> <MtouchExtraArgs>-v -v -v -v</MtouchExtraArgs> </PropertyGroup>
2. Clean and Build
3. Eyeball 1.5MB of build output for something like this
- Look for these
"_EvilMethod", referenced from:
blocks.- second line mentions the dll we are looking for
wrapper_managed_to_native.... in System.Security.AccessControl.dll.o
- in my case
System.Security.AccessControl.dll.o
"_AdjustTokenPrivileges", referenced from: wrapper_managed_to_native_Interop_mincore_AdjustTokenPrivileges_Microsoft_Win32_SafeHandles_SafeTokenHandle_bool_Interop_mincore_TOKEN_PRIVILEGE__uint_Interop_mincore_TOKEN_PRIVILEGE__uint_ in System.Security.AccessControl.dll.o
4. Tell mtouch to dynamically link the dll we identified
Without the trailing
*.o
fromSystem.Security.AccessControl.dll.o
<MtouchExtraArgs>--dlsym:System.Security.AccessControl.dll</MtouchExtraArgs>
5. Go back to Step 3 and repeat for every DLL
My Result:
<MtouchExtraArgs>--dlsym:System.Security.AccessControl.dll --dlsym:System.Security.Principal.Windows.dll --dlsym:System.IO.FileSystem.AccessControl.dll</MtouchExtraArgs>
Or if you don't like long lines, or want do append the args kinda conditionally:
<MtouchExtraArgs>$(MtouchExtraArgs) --dlsym:System.Security.AccessControl.dll</MtouchExtraArgs> <MtouchExtraArgs>$(MtouchExtraArgs) --dlsym:System.Security.Principal.Windows.dll</MtouchExtraArgs> <MtouchExtraArgs>$(MtouchExtraArgs) --dlsym:System.IO.FileSystem.AccessControl.dll</MtouchExtraArgs>
6. Build and Run
7. Peace of mind
I have tried this workaround but when I try to start the app, it crashes after the splashscreen :( Any news on this issue?
Hello,
i had the same issue. my solution was:
<MtouchExtraArgs>$(MtouchExtraArgs) --dlsym:System.Security.Principal.Windows.dll</MtouchExtraArgs>
<MtouchExtraArgs>$(MtouchExtraArgs) --dlsym:System.IO.FileSystem.AccessControl.dll</MtouchExtraArgs>
For sure thats not a normal behavior. For me this happens after updating all my nugets. I try again to reset everything to master and update nuget by nuget to find out some possible indicator.
Hello, works in my case Microsoft.Win32.Registry.dll
Unfortunately the workaround did allow us to build but now the app does not function properly. Haven't found the specific cause yet but our iOS app can no longer connect to our SignalR Hub after adding the following M Touch Arg: --dlsym:System.Security.Principal.Windows.dll
Android app has no problems connecting. Looks like we are going to need to down grade Xamarin.macios
@rlasker-b2w is debug and release affected? If it’s only with Release builds, it might be the linker optimization which is not present in debug Builds.
@juwens this affects anything targeting ARM64 builds so anything that needs to work against a physical device. In my particular case I noticed that my "Ad-Hoc" build that we use for testing version of the app was already set to "No link" and yet were failing due to linking errors. Changing it to "Sdk only" allowed us to build without the dlsym arguments but it still causes our app to no longer be able to connect to our SignalR server. I have not been able to diagnose why it fails in that particular case. Android has no problem connecting to our servers. We currently have no work around for that other than to downgrade Xamarin on our mac build machines.
@rlasker-b2w the problem you have, after applying the build workaround, sounds like a different issue to me. you say, its for ARM64. So if run it on the ios simulator (which is x86 even for M1 Macs) it works fine?
I had kinda similar issues with some nugets respectively the ios build as well. For example System.Text.Json didn't worked for me (and others) and i had to switch to Newtonsoft.Json, because there where issues in the iOS Build. Take a look here, maybe it helps. https://github.com/dotnet/runtime/issues/49940 Or Here https://github.com/xamarin/xamarin-macios/issues/10912
@juwens you ended up being correct. Once I was able to physically debug the app I could see that after getting the builds fixed with the MTouchExtraArgs workaround I saw that we were getting the same issue described here: https://github.com/mono/mono/issues/20805
Thanks to everyone in these threads our builds are running and the app is testable again.
Workaround from @juwens fixed the issue for me. For me the culprit was Microsoft.Win32.Registry.dll
<MtouchExtraArgs>--dlsym:Microsoft.Win32.Registry.dll</MtouchExtraArgs>
Why my Xamarin iOS app is referencing that is a thought provoking question. Cannot wait for .Net 6 to hopefully get past this mess.
How do I get the build output that is mentioned in the workaround. I can't seem to get the same level of verbosity when I add -v -v -v -v. I just have to figure what package is causing the issue
Can someone help me with this one. I tried the work around with System.Net.Security.dll but it didn't work.
This is the only useful error log I can get from building for iPhoneSimulator with Don't Link
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT0030: The executable name (dcbel.Mobile.iOS) and the app name (Debugdcbel.Mobile.iOS.app) are different, this may prevent crash logs from getting symbolicated properly.
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): error : framework not found System
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'System' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'System' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'System' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'System.Net.Security' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'System' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'Kernel32' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'libEGL' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'ole32' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'Kernel32' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'api-ms-win-core-processthreads-l1-1-0' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'api-ms-win-security-base-l1-1-0' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'api-ms-win-core-handle-l1-1-0' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'sspicli' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'api-ms-win-security-lsapolicy-l1-1-0' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'api-ms-win-security-sddl-l1-1-0' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'ntdll' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'api-ms-win-core-heap-obsolete-l1-1-0' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'kernel32' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'crypt32' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'advapi32' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'kernel32' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'ncrypt' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): warning MT5215: References to 'libsecret-1.so' might require additional -framework=XXX or -lXXX instructions to the native linker
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): error MT5201: Native linking failed. Please review the build log and the user flags provided to gcc: -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __entitlements -Xlinker /Users/justin0/Library/Caches/Xamarin/mtbs/builds/dcbel.Mobile.iOS/177dbdb62d7a19e692ba7d974d6d63554980b19b921e92964cd6c96dfef41c88/C:/ossiaco/dcbel_consumer_mobile/artifacts/obj/dcbel.Mobile.iOS/iPhoneSimulator/Debug/Entitlements.xcent
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(380,3): error : linker command failed with exit code 1 (use -v to see invocation)
@justinasfour04 The issue isn't with System.Net.Security it is with a referenced assembly from that package I believe. If the verbose logging as described in the workaround is not working for you then I would try adding all the common assemblies that were potential sources of the issue first to see if that resolves it then back off on the entries to see which specific ones you need:
<MtouchExtraArgs>--dlsym:System.Security.AccessControl.dll</MtouchExtraArgs>
<MtouchExtraArgs>--dlsym:System.Security.Principal.Windows.dll</MtouchExtraArgs>
<MtouchExtraArgs>--dlsym:System.IO.FileSystem.AccessControl.dll</MtouchExtraArgs>
@rlasker-b2w that didn't work for me. Does anyone know how can figure what assemblies are the culprits Where do you even see the build logs?
@justinasfour04 Only other assembly someone mentioned that worked was Microsoft.Win32.Registry.dll ... other than that I would double check how to get the verbose logging from juwens' post to work otherwise it would be difficult to just guess.
That didn't work for me :(
The workaround didn't work for me. I was able to build the app downgrading xcode to v12.4 and xamarin.ios to v14.10.0.4. This will be a problem once Apple updates the version of xcode required to build the app. Is anyone working to fix this?
@juwens work around let me build. Thank you! (i.e. Adding --dlsym:System.Security.AccessControl.dll --dlsym:System.Security.Principal.Windows.dll to MTouch arguments) I upgraded everything and this problem started appearing. Definitely a bug that was not there before. XCode 13 Xamarin.iOS 15 VS for Mac 8.10.11
@HelenMamalaki same version of Xcode, Xamarin.iOS and VS for Mac. Did you found any evil methods like in the workaround of @juwens? I've tried adding MTouch extra args (
I keep getting "Custom command execution failed" when I add "--dlsym:System.Security.Principal.Windows.dll" to the extra arguments
Any news? I need to update my app to the store but still crashes on startup.
I have added
--dlsym:System.Security.AccessControl.dll --dlsym:System.Security.Principal.Windows.dll --dlsym:System.IO.FileSystem.AccessControl.dll --weak-framework=SensorKit.framework/SensorKit
to mtouch as arguments but nothing works!
Xcode 13.2.1 (13C100) Visual Studio for Mac 8.10.15 (build 32) Xamarin.iOS 15.2.0.17
Any news? I need to update my app to the store but still crashes on startup.
I have added
--dlsym:System.Security.AccessControl.dll --dlsym:System.Security.Principal.Windows.dll --dlsym:System.IO.FileSystem.AccessControl.dll --weak-framework=SensorKit.framework/SensorKit
to mtouch as arguments but nothing works!Xcode 13.2.1 (13C100) Visual Studio for Mac 8.10.15 (build 32) Xamarin.iOS 15.2.0.17
in my experience: Don’t expect the Xamarin devs to fix this or to give advice, you are on your own here. Xamarin was abandoned months ago, and all devs were moved to the MAUI marketing train. Or if they reply 1.5 years later, say that the issue is in the wrong location and must be reported in project xyz.
This can't be true.. OMG.. so what should I tell to our clients? "sorry but we are using a s**t of software to make the app and now we don't have any support".. Wow nice move MS.. I'll try to contact the business support.
Thank you for the reply :)
Update: might be related to this change in 14.14 #10182
pretty similar to #10855 we just recently have a problem building only our Release|arm64 build with Xamarin.ios 14.14
Might be a bad Nuget package as well.
Steps to Reproduce
Expected Behavior
Release|ARM64 doesn't fail with linking errors on _CompileToNative If it fails, there should be some hint, on which Nuget package to look at.
Actual Behavior
Release|ARM64 fails with errors/warnings
Environment
Build Logs
whole verbose log
Logging from error to end
Example Project (If Possible)