-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Conversation
Tagging subscribers to this area: @dotnet/area-system-globalization Issue DetailsAfter #93220 xamarin-macios build is failing because of not recognising targets properly.
|
/azp run runtime-maccatalyst |
/azp run runtime-ioslikesimulator |
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-ioslike |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-ioslike |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-maccatalyst |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-ioslikesimulator |
Azure Pipelines successfully started running 1 pipeline(s). |
@@ -107,6 +107,13 @@ else() | |||
endif() | |||
|
|||
if (CLR_CMAKE_TARGET_APPLE) | |||
if(CLR_CMAKE_TARGET_IOS) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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:
- directly into the mono runtime
- 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
xamarin-macios
maybe is takingsrc/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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
xamarin-macios
maybe is takingsrc/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, andconfigurecompiler
is ultimately included by this cmake list. If xamarin is skippingconfigurecompiler
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.
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.
There was a problem hiding this comment.
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 fromsrc/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:runtime/src/mono/mono/mini/CMakeLists.txt
Lines 429 to 431 in 806c365
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 useconfigurecompiler.cmake
andconfigureplatform.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 caselibSystem.Globalizaiton.Native.a
is built fromsrc/native/libs/CMakeLists.txt
which includesconfigureplatform.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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverting this PR #96658
/azp run runtime-maccatalyst |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-ioslikesimulator |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-ioslike |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-ioslike,runtime-ioslikesimulator,runtime-maccatalyst |
Azure Pipelines successfully started running 3 pipeline(s). |
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. |
I'm gonna hit merge, @rolfbjarne seems happy enough and I don't see how any of the failing tests are related. |
…CU change (dotnet#96270)" (dotnet#96658) This reverts commit ab8c3b8.
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
andsrc/native/libs/System.Globalization.Native/CMakeLists.txt