Clang++ exited with code 1 - Duplicate Symbols #19378
Comments
|
Would you be able to share the BlueRadioBrsp64 NuGet (.nupkg file) with us? |
rolfbjarne
added
the
need-info
|
@rolfbjarne Do you have a way I can send it directly to you? I am not allowed to share it publicly, but I have permission to send it to you for support. It's a binding library to communicate with a proprietary Bluetooth sensor. |
microsoft-github-policy-service
bot
added
need-attention
If you create a new feedback ticket here: https://developercommunity.visualstudio.com/VisualStudioMac/report, you can add private attachments afterwards. Explain in the ticket that you're just adding private information to this issue, and post a link here to the feedback ticket so I can link them up. |
|
Submitted and attached the files. Here's the link to the ticket: https://developercommunity.visualstudio.com/t/Clang-exited-with-code-1---Duplicate-S/10506451 |
|
Can you try adding setting <PropertyGroup>
<CompressBindingResourcePackage>true</CompressBindingResourcePackage>
</PropertyGroup> |
rolfbjarne
added
need-info
microsoft-github-policy-service
bot
added
need-attention
|
That allows me to build, but now when accessing the library the app crashes. When looking back through the build logs, I now see this warning: |
That looks like a missing entry in your Info.plist for some feature iOS will show a permission dialog about. You should get a somewhat better crash report if you disable stripping in your csproj: <PropertyGroup>
<NoSymbolStrip>true</NoSymbolStrip>
</PropertyGroup>that might reveal a bit more. |
|
I had to examine the device log, but you were correct, I was missing a few lines from my Info.plist. I'm able to build, deploy, and access the native library again. Perhaps there should be some documentation about potentially needing in the csproj file? Either way, your help is greatly appreciated as I've spent the last several days trying to figure this out. |
It shouldn't be needed, it's a bug on our side somewhere. I'll look into it. |
rolfbjarne
added
regression
|
Thanks. Let me know if I can provide any more information. |
|
@rolfbjarne I just wanted to let you know, I was incorrect. The app doesn't crash, but I'm unable to actually interact with the library. Everything is blank/null when trying to reference anything from the library. For example, we scan for Bluetooth devices using a CBUUID from the library, but the property is empty, I'm still seeing the MT1308 warning I mentioned before, so it's like it's linking, but not including the native library. Hard to really describe. I can provide the intermediate project that we use to interact with the sensors if that would help. |
|
Here's a binlog with that added: binlogs.zip |
|
OK, try this instead: <PropertyGroup>
<NoBindingEmbedding>false</NoBindingEmbedding>
</PropertyGroup> |
|
No change, still null references. |
|
Ah sorry I was unclear, the NoBindingEmbedding=false property goes in the binding project. |
|
Sadly, still no change. |
|
The native library However, I looked at your ApiDefinition.cs, and it looks like the interface definition for the Brsp type is wrong: it doesn't look like a protocol, in which case you should remove the [Protocol] attribute. Can you try that and see if it makes a difference? |
…dotnet-linker. Fixes xamarin#19378. We currently detect/resolve binding resource packages (the sidecar) in two places: * The ResolveNativeReferences MSBuild task. * Inside mtouch/mmp/dotnet-linker. Which means we end up passing every native library or framework twice to the native linker. This is usually not a problem, the native linker will ignore duplicated arguments, except when building remotely from Windows, in which case the build process may end up with native libraries in different locations, because files may end up in multiple places on the remote Mac if using absolute paths (see xamarin#18997 for a thorough explanation). So completely remove the logic to detect/resolve binding resource packages in mtouch/mmp/dotnet-linker, which will avoid the issue completely. Fixes xamarin#19378.
|
No change, unfortunately. It's odd because the ApiDefinition and StructsAndEmums are direct copy-paste from the original Xamarin.iOS binding project which works perfectly. |
|
Can you create a test project that shows the problem and attach it to the feedback ticket you created earlier? |
|
Here's an interesting development: I copied the BlueRadioBrsp64 project into a new MAUI solution, added the project reference, and copied the bare minimum of files from the intermediate library I was using, and the fresh MAUI solution was able to properly utilize the native library. So there's something messed up in my current solution. I'm going to do some digging to figure out what's going on and will update later. |
|
Ok, after cleaning up my entire environment (including removing the .vs folder and csproj.user files), updating Visual Studio, then copying all of the changes you've suggested into the Nuget solution and rebuilding, I'm now able to utilize the library in the app. Thank you so much for the assistance, and let me know if I can provide any more information. |
…dotnet-linker. Fixes #19378. (#19407) We currently detect/resolve binding resource packages (the sidecar) in two places: * The ResolveNativeReferences MSBuild task. * Inside mtouch/mmp/dotnet-linker. Which means we end up passing every native library or framework twice to the native linker. This is usually not a problem, the native linker will ignore duplicated arguments, except when building remotely from Windows, in which case the build process may end up with native libraries in different locations, because files may end up in multiple places on the remote Mac if using absolute paths (see #18997 for a thorough explanation). So completely remove the logic to detect/resolve binding resource packages in mtouch/mmp/dotnet-linker, which will avoid the issue completely. A few mtouch tests also needed updating, since they're calling mtouch directly instead of going through the msbuild targets. Fixes #19378.
…dotnet-linker. Fixes xamarin#19378. We currently detect/resolve binding resource packages (the sidecar) in two places: * The ResolveNativeReferences MSBuild task. * Inside mtouch/mmp/dotnet-linker. Which means we end up passing every native library or framework twice to the native linker. This is usually not a problem, the native linker will ignore duplicated arguments, except when building remotely from Windows, in which case the build process may end up with native libraries in different locations, because files may end up in multiple places on the remote Mac if using absolute paths (see xamarin#18997 for a thorough explanation). So completely remove the logic to detect/resolve binding resource packages in mtouch/mmp/dotnet-linker, which will avoid the issue completely. Fixes xamarin#19378.
…ges in mtouch/mmp/dotnet-linker. Fixes xamarin#19378. (xamarin#19463) We currently detect/resolve binding resource packages (the sidecar) in two places: * The ResolveNativeReferences MSBuild task. * Inside mtouch/mmp/dotnet-linker. Which means we end up passing every native library or framework twice to the native linker. This is usually not a problem, the native linker will ignore duplicated arguments, except when building remotely from Windows, in which case the build process may end up with native libraries in different locations, because files may end up in multiple places on the remote Mac if using absolute paths (see xamarin#18997 for a thorough explanation). So completely remove the logic to detect/resolve binding resource packages in mtouch/mmp/dotnet-linker, which will avoid the issue completely. A few mtouch tests also needed updating, since they're calling mtouch directly instead of going through the msbuild targets. Fixes xamarin#19378. Backport of xamarin#19407 --------- Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
I'm encountering an issue while trying to build a project that's referencing a native binding library.
The binding project was created with .NET 7, and builds an runs with a .NET 7 project. However, in a .NET 8 project, the build fails due to "duplicate symbols" and "duplicate libraries"
I have verified that the library does not contain duplicate symbols using the method from Xamarin.iOS Errors
Here is the fgrep output for one of the symbols the log says is duplicated:
The output is reporting that literally every symbol in the library is a duplicate.
It seems like it's trying to link from both the local path on my Windows laptop and from the remote path on the MacBook, as it's listed twice in the clang++ arguments.
I've tried multiple solutions presented in various other issues, and nothing changes.
Steps to Reproduce
Expected Behavior
App builds and is able to utilize native library
Actual Behavior
Build fails with false duplicate symbol errors.
Environment
Windows Development Environment
MacOS Development Environment
Version information
Build Logs
msbuild-asnuget.zip
msbuild-asproject.zip
Example Project (If Possible)
I'm unable to provide an example project, as the library is proprietary, and we don't have permission to share it.
The text was updated successfully, but these errors were encountered: