[NativeAOT] Fix iOS library build by linking standard C++ library by default

[ivanpovazan]

This PR fixes building an iOS-like NativeAOT libraries by linking standard C++ library by default.

Recently we started statically linking ICU libraries when targeting iOS-like platforms in: #90430
However globalization and ICU support has a dependency on the standard C++ lib which is not included by NativeAOT build integration targets and produces a build error when trying to build NativeAOT iOS library:

Undefined symbols for architecture arm64:
    "std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*))", referenced from:
        void std::__1::call_once<void (&)()>(std::__1::once_flag&, void (&)()) in libicuuc.a(umutex.ao)
        ...

This is not visible when build iOS apps, as we use AppleAppBuilder and Xamarin application bundlers that are taking care of native linking.

NativeAOT with iOS in library mode is not officially supported (this is tracked in: #88737), but this fix is a prerequisite of going in the right direction and unblocking customers who are using the experimental support. The official support for iOS library mode will come in a separate PR.

---

Fixes: #91997

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This PR fixes building an iOS-like NativeAOT libraries by linking standard C++ library by default.

Recently we started statically linking ICU libraries when targeting iOS-like platforms in: #90430
However globalization and ICU support has a dependency on the standard C++ lib which is not included by NativeAOT build integration targets and produces a build error when trying to build NativeAOT iOS library:

Undefined symbols for architecture arm64:
    "std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*))", referenced from:
        void std::__1::call_once<void (&)()>(std::__1::once_flag&, void (&)()) in libicuuc.a(umutex.ao)
        ...

This is not visible when build iOS apps, as we use AppleAppBuilder and Xamarin application bundlers that are taking care of native linking.

NativeAOT with iOS in library mode is not officially supported (this is tracked in: #88737), but this fix is a prerequisite of going in the right direction and unblocking customers who are using the experimental support. The official support for iOS library mode will come in a separate PR.

---

Fixes: #91997

Author:	ivanpovazan
Assignees:	ivanpovazan
Labels:	area-NativeAOT-coreclr
Milestone:	-

[ivanpovazan]

/cc: @steveisok

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[steveisok]

@ivanpovazan @rolfbjarne this doesn't clash with anything in the iOS sdk, right?

[ivanpovazan]

@ivanpovazan @rolfbjarne this doesn't clash with anything in the iOS sdk, right?

I do not think it should. I manually tested building/running a MAUI iOS sample app by explicitly passing -p:LinkStandardCPlusPlusLibrary=true with the RC1 release and did not have any issues.

[rolfbjarne]

@ivanpovazan @rolfbjarne this doesn't clash with anything in the iOS sdk, right?

It shouldn't, at most we'd pass the same linker argument twice to the native linker.

[jkotas]

Thanks

[ivanpovazan]

/backport to release/8.0

[github-actions]

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6201366248

[ivanpovazan]

/azp run runtime-ioslike

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ivanpovazan]

The failures are unrelated and are being tracked.