Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[HybridGlobalization] Fix xamarin_macios build after system ICU change #96270

Merged
merged 4 commits into from
Jan 5, 2024

Conversation

mkhamoyan
Copy link
Contributor

After #93220 xamarin-macios build is failing because of not recognising targets properly.
Issue is that this gives false and it wants to define wrong set of functions.
With this PR adding target definitions also in src/mono/mono/mini/CMakeLists.txt and src/native/libs/System.Globalization.Native/CMakeLists.txt

@ghost
Copy link

ghost commented Dec 22, 2023

Tagging subscribers to this area: @dotnet/area-system-globalization
See info in area-owners.md if you want to be subscribed.

Issue Details

After #93220 xamarin-macios build is failing because of not recognising targets properly.
Issue is that this gives false and it wants to define wrong set of functions.
With this PR adding target definitions also in src/mono/mono/mini/CMakeLists.txt and src/native/libs/System.Globalization.Native/CMakeLists.txt

Author: mkhamoyan
Assignees: -
Labels:

area-System.Globalization, os-ios

Milestone: -

@ghost ghost assigned mkhamoyan Dec 22, 2023
@mkhamoyan
Copy link
Contributor Author

/azp run runtime-maccatalyst

@mkhamoyan
Copy link
Contributor Author

/azp run runtime-ioslikesimulator

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

1 similar comment
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mkhamoyan
Copy link
Contributor Author

/azp run runtime-ioslike

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mkhamoyan
Copy link
Contributor Author

/azp run runtime-ioslike

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mkhamoyan
Copy link
Contributor Author

/azp run runtime-maccatalyst

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mkhamoyan
Copy link
Contributor Author

/azp run runtime-ioslikesimulator

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@@ -107,6 +107,13 @@ else()
endif()

if (CLR_CMAKE_TARGET_APPLE)
if(CLR_CMAKE_TARGET_IOS)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vargaz Do you think this block is also unnecessary?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That might be needed, those defines are not set in that project. I think the issues is that in some cases these files are compiled as part of the mono runtime, and sometimes they are compiled into a separate lib ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, when I build runtime locally I see that we compile the globalization code twice:

  1. directly into the mono runtime
  2. from src/native/System.Globalization.Native

That is why I don't see any failure on runtime, but xamarin-macios maybe is taking src/native/System.Globalization.Native compiled into separate lib.

Copy link
Member

@am11 am11 Dec 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

xamarin-macios maybe is taking src/native/System.Globalization.Native compiled into separate lib.

I am not sure how is it possible for xamarin to skip cmake inclusions needed to build this cmake list? These TARGET_XX variables are defined in eng/native/configurecompiler.cmake along with many compiler flags, and configurecompiler is ultimately included by this cmake list. If xamarin is skipping configurecompiler include somehow (which seems unlikely), then fixing it this way won't be enough as it will break something else. We should fix xamarin build instead so it builds the runtime's native lib subset properly as intended; with the entire cmake include chain.

cc @jkoritzinsky, @akoeplinger

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

xamarin-macios maybe is taking src/native/System.Globalization.Native compiled into separate lib.

I am not sure how is it possible for xamarin to skip cmake inclusions needed to build this cmake list? These TARGET_XX variables are defined in eng/native/configurecompiler.cmake along with many compiler flags, and configurecompiler is ultimately included by this cmake list. If xamarin is skipping configurecompiler include somehow (which seems unlikely), then fixing it this way won't be enough as it will break something else. We should fix xamarin build instead so it builds the runtime's native lib subset properly as intended; with the entire cmake include chain.

cc @jkoritzinsky, @akoeplinger

xamarin/xamarin-macios doesn't build anything from dotnet/runtime, we consume the static/dynamic libraries dotnet/runtime ships. The problem is that those libraries aren't built correctly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is still mystery to me why the change in this file is needed. Why are these defines not getting picked up from eng/native/configurecompiler.cmake as @am11 pointed out?

Have we validated that this change is actually fixing the problem?

In xamarin-macios, dotnet/runtime artifacts are consumed in two different ways:

  • For some scenarios a single libmonosgen-2.0.dylib is consumed: this file is built from src/mono/mono/mini/CMakeLists.txt and it includes a copy of System.Native.Globalization. This version of the globalization code is built by these rules: https://github.com/dotnet/runtime/blob/main/src/mono/mono/mini/CMakeLists.txt#L59-L111. and is consumed here:

    if(HAVE_ICU_SHIM)
    target_link_libraries(monosgen-shared PRIVATE icu_shim_objects)
    endif()

    In this case the cmake defines that are floating around are coming from how the mono runtime is configured (which does not yet use configurecompiler.cmake and configureplatform.cmake).

  • For some scenarios xamarin-macios instead consumes a collection of static libraries: libmono-sgen-2.0.a, libSystem.Globalization.Native.a, libmono-component-debugger.a etc. In this case libSystem.Globalizaiton.Native.a is built from src/native/libs/CMakeLists.txt which includes configureplatform.cmake, but does not include the plethora of Mono definitions.

On the other hand, the C source files comprising src/native/libs/System.Globalization.Native depend on defines like TARGET_MACCATALYST that are part of the mono build, but weren't yet part of the build for the static libSystem.Globalization.Native.a.

By the way @mkhamoyan there's similar logic in https://github.com/dotnet/runtime/blob/main/src/native/libs/System.Security.Cryptography.Native.Apple/CMakeLists.txt#L60-L70. Maybe it would make more sense to move it up to src/libs/native/CMakeLists.txt or to some common .cmake fragment, instead?

Also - I'm not sure why we link the icu shim directly into libmonosgen-2.0.dylib - I'm pretty sure we don't do that with crypto, but we can apparently still ensure that the symbols are available at runtime so that all the pinvokes can find them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the C source files comprising src/native/libs/System.Globalization.Native depend on defines like TARGET_MACCATALYST that are part of the mono build, but weren't yet part of the build for the static libSystem.Globalization.Native.a.

I do not think that this is correct. These defines are defined in configurecompiler.cmake too. For example, TARGET_MACCATALYST is defined at https://github.com/dotnet/runtime/blob/main/eng/native/configurecompiler.cmake#L697 .

I expect that we are going to find that this fix is not addressing the xamarin-macios build break.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think that this is correct. These defines are defined in configurecompiler.cmake too.

I expect that we are going to find that this fix is not addressing the xamarin-macios build break.

Yea, I agree now, I don't see how this change would fix anything.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I don't think it addresses it either. @mkhamoyan pointed this out to me earlier today in that the xamarin build may need to be modified because only a subset of the pinvokes will be active since we are shipping with hybrid globalization always on. We plan on adding the ability to turn it off and use our ICU in a later change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverting this PR #96658

@mkhamoyan
Copy link
Contributor Author

/azp run runtime-maccatalyst

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mkhamoyan
Copy link
Contributor Author

/azp run runtime-ioslikesimulator

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mkhamoyan
Copy link
Contributor Author

/azp run runtime-ioslike

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@directhex
Copy link
Contributor

/azp run runtime-ioslike,runtime-ioslikesimulator,runtime-maccatalyst

Copy link

Azure Pipelines successfully started running 3 pipeline(s).

@directhex
Copy link
Contributor

There are a lot of test failures, but I think this PR is innocent.

iOS and tvOS failures are dotnet/xharness#1126 & dotnet/dnceng#1749

Mac Catalyst failures are PNSE in System.Security.Cryptography.X509Certificates.Tests.CertTests.PublicPrivateKey_IndependentLifetimes_DSA() which is unrelated to this PR

browser-wasm failure is assertion issues in System.Runtime.InteropServices.JavaScript.Tests.WebWorkerTest.ManagedDelay_ContinueWith which, again, seems unrelated to these changes.

@directhex
Copy link
Contributor

I'm gonna hit merge, @rolfbjarne seems happy enough and I don't see how any of the failing tests are related.

@directhex directhex merged commit ab8c3b8 into dotnet:main Jan 5, 2024
197 of 212 checks passed
mkhamoyan added a commit that referenced this pull request Jan 9, 2024
jkotas pushed a commit that referenced this pull request Jan 9, 2024
tmds pushed a commit to tmds/runtime that referenced this pull request Jan 23, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Feb 9, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants