Error MT5210: Linking fails for Release| ARM64 Builds; works fine for: "iPhone Simulator Release|x86_64", "iPhone Debug|ARM64", etc #10884
Comments
juwens
changed the title
juwens
changed the title
|
I'm seeing something similar in the latest release: 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. 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. |
|
Turns out a reference to the |
|
Same issue here... |
|
We have also this issue! |
|
I'm trying to create a minimal example. |
This comment has been minimized.
This comment has been minimized.
|
Found this in the build output. But then directly after the |
juwens
changed the title
|
I've found a workaround. 1. Enable verbose mtouch buildBy adding 2. Clean and Build3. Eyeball 1.5MB of build output for something like this
4. Tell mtouch to dynamically link the dll we identifiedWithout the trailing 5. Go back to Step 3 and repeat for every DLLMy Result:Or if you don't like long lines, or want do append the args kinda conditionally:6. Build and Run7. Peace of mind |
|
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. |
|
In the release notes of 14.14 I've found this suspicious candidate for the regression #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. |
mandel-macaque
added
bug
|
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. |
mandel-macaque
added
need-info
|
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 |
|
@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. |
|
@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 (--dlsym:System.Security.AccessControl.dll --dlsym:System.Security.Principal.Windows.dll --dlsym:System.IO.FileSystem.AccessControl.dll |
chamons
added
bug
|
I keep getting "Custom command execution failed" when I add "--dlsym:System.Security.Principal.Windows.dll" to the extra arguments |
|
Any news? I have added Xcode 13.2.1 (13C100) |
in my experience: |
|
This can't be true.. OMG.. so what should I tell to our clients? Thank you for the reply :) |
@Raystorm7 did you try the workaround I found? This could help you in the short term. |
|
Thank you @gasblack but I need to compile for iOS 15.x and those versions don't allow it :( |
|
This has helped my build, it might help others:
|
|
Adding the -all argument didn't help us :( |
|
any update on this issue? |
rolfbjarne
added
the
need-info
|
We need a way to reproduce the problem in order to figure out what's going on. If anybody can provide a project we can use for this purpose (it doesn't have to be a minimal project, it can be your real project), we're eager to investigate. |
|
@rolfbjarne You can use mine. Remove line 97-105 (the workaround described in this thread) of "Sags Wien Neu.iOS.csproj" in order to reproduce it. |
|
@Matti-Koopa that builds fine for me locally (I assume you're building Release for device?) Can you execute this from a terminal: and then attach the resulting msbuild.binlog file here? That should provide me with all the version information and build output to figure out where our builds differ. |
Same here, builds fine (after changing signing certs and removing the aforementioned lines). |
|
Workaround seems to be: Restart VS and THEN reconnect to Mac, clean all and rebuild. |
|
Hi @juwens. Due to inactivity, we will be closing this issue. Please feel free to re-open this issue if the issue persists. For enhanced visibility, if over 7 days have passed, please open a new issue and link this issue there. Thank you. |
ghost
closed this as
|
Wait one year without fixing the problem. Close ticket. Done. |
|
This means that Xamarin Forms is dead? |
|
Hello Folks
We implemented a cleanup bot to help us better maintain our issues list, we requested info (need-info) because we were not able to reproduce this ourselves but got no response yet.
Definitely no, it is still being maintained but the main focus is now MAUI. Please if you are able to provide a test case / project that we can use to repro feel free to re-open this issue or create a new one and we will have a look at it. |
|
any update on this issue? |
appcenter anonimized build log with this issue: |
ℹ️ We need a way to reproduce the problem in order to figure out what's going on. ℹ️ If anybody can provide a project we can use for this purpose (it doesn't have to be a minimal project, it can be your real project), we're eager to investigate. I'm going to lock this issue so that this is the last comment (and thus more visible). If you can provide a project we can use to reproduce the problem, please open a new issue and link back to this one. I repeat: we're happy to investigate, but we need a way to reproduce it ourselves. |
|
For the following scenario:
See #17387 for potential workarounds/solutions. |
and others
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)
The text was updated successfully, but these errors were encountered: