OSX 10.9 support / libicui18n

[christianscheuer]

When running a corert-based app on OSX 10.9, I get the following error:

Cannot get symbol ucol_setMaxVariable from libicui18n
Abort trap: 6

Is there any way to link a version of libicui18n statically with corert to make it work on 10.9? I know that there probably isn't gonna be official support for 10.9 but since many of our customers are on old systems, it would be great to get a starting point on how to debug this, so we at least could make it work in a fork.

[MichalStrehovsky]

The reference is most likely coming from System.Globalization.Native.a that we link against.

If there is a static version of libicui18n, what might work is removing the reference to the one provided by the build scripts and adding the static one as an <AdditionalNativeLibrary>. If that works, we can make the inclusion of -licucore conditional based on a property so that it can be made to work with the published ILCompiler packages.

[jkotas]

libicu is big. I do not think you would want to link it statically. I think viable options are:

• Build System.Globalization.Native.a without HAVE_SET_MAX_VARIABLE set. It will use an alternative hacky replacement for this API: https://github.com/dotnet/coreclr/blob/ce9bc942510fc9608c24e938f6d043c39fd0085d/src/corefx/System.Globalization.Native/collation.cpp#L277

• If you do not really need globalization (culture specific sorting, etc.), we have globalization invariant mode in .NET: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/globalization-invariant-mode.md . This mode makes only invariant culture available to the app and avoids dependency on libicu. We do not have this fully wired in CoreRT yet (again it depends on reconciliation of the fork with CoreCLR).

The major missing dependency for 10.9 is crypto stack. .NET Core crypto stack on Mac has a major dependency on new OSX 10.11 crypto APIs. This dependency is basically the reason why we do not have support for older OSX versions.

[christianscheuer]

Great, thank you both for the quick response! We could definitely work around both the need for culture specific .NET api's and crypto. And in case we should need it, we could just p/invoke to the Mac specific libraries directly.

Having a flag to only use the invariant culture and exclude libicu from the build would definitely be great in the long run, once the reconciliation is done, so we could stick to the offical CoreRT package eventually.

How would the story be for the crypto stack? I guess if we simply avoid having dependencies on any crypto .NET api's then it will solve itself. We were considering switching from our native placeholder http server implementation that we currently link in via AdditionalNativeLibrary to ASP.net (that has been there because CoreRT support for ASP.net was not ready when we started developing) but I suppose ASP.net Core is dependent on the crypto stack, if I'm not mistaken?

[jkotas]

I suppose ASP.net Core is dependent on the crypto stack

Yes, I would expect ASP.NET Core to depend on the crypto stack.