Reopening issue #8669 Xamarin.iOS native linking error MTOUCH MT5210 undefined symbol std::string

[j2bmw]

The provided Xcode project included several dynamic frameworks when building its sample. Those were not included in the Xamarin project. Once added (as more Native References) the build succeeded.

Originally posted by @spouliot in #8669 (comment)

It seems the iOS native linking error was not resolved properly. Although the iOS project is linked and built after referencing dynamic frameworks, there is a runtime issue. Our SDK provider confirmed that we must not use their dynamic frameworks. The dynamic frameworks are provided for other customers for a different target SimpleDemo_Dy in Xcode. They are older versions SDK. We should just use the static libraries.

I have re-examined the Xcode build log. No dynamic frameworks are used for target SimpleDemo in Xcode. The question is why Xcode project builds without using any dynamic frameworks, but Visual Studio for Mac build fails with a native linking error?

[j2bmw]

I’ve created a sample iOS app which only uses static libraries. It builds and runs OK. I've shared the sample iOS app with you. The link is https://drive.google.com/file/d/10QXkaZE7lURN6IF96NIrTGY2lmn88ctF/view?usp=sharing.

I haven’t been able to achieve the same in our product app with identical binding project settings. I even tried to swap the binding project from the sample app. It didn't help. Also I compared the iOS project settings from project options UI and WinMerge. I still couldn't find what's wrong. I have tried clean and rebuild many times. I have tried to check out to a fresh workspace. It still has undefined symbol error.

I think the issue is one of the native libraries libHCCore.a is compiled with libstdc++ which caused the error undefined symbol std::string while the rest are libc++.

Adding Linker Flags -lstdc++ to the native reference didn't help. How to used additional Mtouch arguments in iOS project or additional btouch arguments in binding project to resolve the issue?

[spouliot]

@j2bmw here's a copy to my reply to your email

Bonjour Hong,

Just let you know that I’ve created a sample iOS app which only uses static libraries. It builds and runs OK.

That was a very good idea! IIRC (I would need to redownloaded the previous projects) your application was using other binding projects, right ?

Some linker settings are global to your application. It means that X might require A and Y might not work with A. This is not common but it can happen, e.g. if both bindings projects (X and Y) are built with different versions of the C++ runtime library.

It’s also possible for library J to expose symbol L and for library K to expose another symbol L – since there’s no namespace, like in C#, for symbol names. This normally would show warnings that I did not see (or remember in your project).

Basically the static libraries (part of the binding project) are not self-contained. IOW they refer to code that’s outside them, most commonly in the operating system but it can also be in other static (or dynamic) libraries.

It’s the native linker job to ensure that every required symbols is present in the final (application) binary. If it cannot find all required symbols then you’ll get errors (like the ones you have).

So your 3rd-party video bindings are not complete. It’s not necessarily a bug, that’s how most things ship, building on other’s code.

When you build your “new” sample, the native linker is able to find all it needs -> good

When you build your “old” sample then it complained things were missing -> bad

When you build your “old” sample with the dynamic libraries then it found everything -> good (at least for building)

What likely happen is that the dynamic libraries contains the “missing” symbols (but does not means it’s the only, or even correct, way to get the symbols). That made the native linker happy since everything resolved and it could produce a final binary. Having all symbols does not means they are all fine to use together. The runtime error might (or not) be related to this.

That brings me back to #2, something (likely another binding project) is partially solving the linker requirement, instead of the correct library. That’s why errors are reported. Why partial ? because something else gets used (from another binding project). If that was not the case then it would be identical to #1.

That’s the logic behind it.

The best approach I can suggest is divide-and conquer. Remove*, one by one, the other bindings projects from your application. At some point you should get the app working and that will mean the last removed binding project is the culprit (if unlucky there might be more than one).

• alternatively add them, one by one, to your new sample – it might be simpler this way. Just make sure that the code is used, otherwise the linker will eliminate it and that will hide the error.

At this stage you should know what binary (or binaries) are incompatible with your Video bindings.

Sadly there’s not much I (or Microsoft) can do to solve 3rd party binary incompatibilities. Apple provides the native linker and the 3rd party libraries comes from different vendors, which likely never tested their code together. Your best option would be to get both vendors to talk about their linker settings/dependencies and see if they can come up with a solution for them to work together.

Sebastien

[spouliot]

I think the issue is one of the native libraries libHCCore.a is compiled with libstdc++ which caused the error undefined symbol std::string while the rest are libc++.

You can't mix both.

Building with libstdc++ was deprecated with Xcode 8 and is not supported in Xcode 10 when targeting iOS. C++ projects must now migrate to libc++ and are recommended to set a deployment target of macOS 10.9 or later, or iOS 7 or later.

...

Project dependencies such as static archives that were built against libstdc++ will also need to be rebuilt against libc++.

https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes?language=objc

You'll need to talk with your vendor to get an updated that is built against libc++

[j2bmw]

Thanks for your quick response. It helps.

[chrisfoulds]

Possible related ?
xamarin/GoogleApisForiOSComponents#423

[rolfbjarne]

Closing according to second to last comment.