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

Should globalization native shim support older ICU versions on alpine? #13527

Closed
safern opened this issue Oct 3, 2019 · 1 comment · Fixed by dotnet/coreclr#27042
Closed
Labels
area-System.Globalization bug os-linux Linux OS (any supported distro)
Milestone

Comments

@safern
Copy link
Member

safern commented Oct 3, 2019

The coreclr musl build was moved to now build on alpine-3.9. If people try to use a build of the product that contains latest .NET 5 coreclr on < alpine-3.9 and hits any globalization path, it would fail with:

Process terminated. Couldn't find a valid ICU package installed on the system. Set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support.
at System.Environment.FailFast(System.String)
at System.Globalization.GlobalizationMode.GetGlobalizationInvariantMode()
at System.Globalization.GlobalizationMode..cctor()
at System.Globalization.GlobalizationMode.get_Invariant()
at System.Globalization.CultureData.CreateCultureWithInvariantData()
at System.Globalization.CultureData.get_Invariant()
at System.Globalization.CultureInfo..cctor()
at System.Globalization.CultureInfo.get_CurrentCulture()

The reason for that is because we try to load the ICU version that we compiled against (defined in the headers) and 20+ versions of it.
https://github.com/dotnet/coreclr/blob/190888373afe4f526de2bd7f366ffe53cced0325/src/corefx/System.Globalization.Native/pal_icushim.c#L57-L58

@janvorli commented:

"The reason to not to always start from the version 50 (the first one that we can possibly work with and the one present on CentOS 7) was to ensure that we do a minimal amount of scanning when we build for specific distro. Another reason was that on glibc based distros, build from a newer distro can never work on an older one anyways.
The MUSL based distros are different though, build created on a newer Alpine actually works on an older one, so it would make sense to make the initial version constant for MUSL based distros (I would use the version from 3.6)
"

For more details see: dotnet/corefx#41280 (comment)

cc: @wfurt @jkoritzinsky

@xiangzhai
Copy link
Contributor

Hi,

Workaround:

export CLR_ICU_VERSION_OVERRIDE="52.1"

For other older libicu:

$ rpm -ql libicu
/usr/lib64/libicudata.so.52
/usr/lib64/libicudata.so.52.1
/usr/lib64/libicui18n.so.52
/usr/lib64/libicui18n.so.52.1
/usr/lib64/libicuio.so.52
/usr/lib64/libicuio.so.52.1
/usr/lib64/libicule.so.52
/usr/lib64/libicule.so.52.1
/usr/lib64/libiculx.so.52
/usr/lib64/libiculx.so.52.1
/usr/lib64/libicutest.so.52
/usr/lib64/libicutest.so.52.1
/usr/lib64/libicutu.so.52
/usr/lib64/libicutu.so.52.1
/usr/lib64/libicuuc.so.52
/usr/lib64/libicuuc.so.52.1
...

Thanks,
Leslie Zhai

@msftgits msftgits transferred this issue from dotnet/coreclr Jan 31, 2020
@msftgits msftgits added this to the 5.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Globalization bug os-linux Linux OS (any supported distro)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants