Support OSX

[ermshiperete]

macOS uses dylib files instead of so and the file pattern is libicuuc.[version].dylib instead of libicuuc.so.[version], so our current approach for loading unmanaged ICU doesn't work.

The relevant code is in source/icu.net/NativeMethods/NativeMethods.cs.

See discussion on Slack.

[ermshiperete]

See also #141

[rmunn]

Since the Slack discussion may not be accessible to everyone (e.g., any open-source contributors who might find this), here's the important parts from the discussion:

Relevant code from source/icu.net/NativeMethods/NativeMethods.cs:

icu-dotnet/source/icu.net/NativeMethods/NativeMethods.cs

Line 336 in ec6f567

var libName = $"lib{basename}.so.{icuVersion}";

Relevant comment from Slack discussion:

It looks like we always assume non-Windows OSes name their libraries with .so. However, macOS (at least Catalina) uses dylib files, not so files. Also, while we assume the icuuc library would be libicuuc.so.[version], on macOS it looks like the file pattern is libicuuc.[version].dylib. On top of that, I only see icu4c available on macOS if you install Homebrew or build it yourself. (libicuuc is part of the icu4c package)

It looks like #142 was an attempt to fix this issue, but didn't completely solve it.

sillsdev/TheCombine#927 is probably caused by this as well.

[imnasnainaec]

@rmunn I was hoping to try out a fix on my mac: master...imnasnainaec:icu-dotnet:mac

...but I'm not sure how to build on/for macOSX to test it out.

(Attempting: #188)

[chrisvire]

@ermshiperete What is the state of this issue?

[imnasnainaec]

At least for its use in The Combine, the current hurdle is getting icu-dotnet to find my libicuuc. I'm not sure yet whether there's more required from the icu-dotnet side of things or if it's a matter of local setup.

[rmunn]

One issue I've discovered is that depending on how you installed icu4c, the installed .dylib files might not be on the standard library search path. Yesterday we tried running brew install icu4c and it installed libicuuc.74.2.dylib (and a libicuuc.74.dylib symlink) into /opt/homebrew/Cellar/icu4c/lib (I think, I'll have to go back and check).

One thing that might help is https://github.com/sickcodes/Docker-OSX which builds off the work done by https://github.com/kholia/OSX-KVM. Running Mac OS in a Docker container might allow automated testing, so we can make sure icu.net can find the libraries in all common install scenarios.

[lyonsil]

For Platform.Bible we bundle in the icu4c libraries along with our application builds so we don't have to worry about this. Since OSX doesn't provide them we assume we can't rely on them being anywhere in the path.

[imnasnainaec]

For reference, prs #194, #198, #200 were toward resolving this issue.

[rgn]

Just wanted to give it a try and installed icu @76.1 and updated the project file to ensure that the icu.net.dll.config files exists in the output.

When running my application I get Can't load ICU library (version 0).

What is the required version or is there anything to be done that the libraries can be found? What can I do to debug the issue?
I haven't found anything in the available docs.

https://github.com/sillsdev/icu-dotnet/blob/master/source/icu.net/IcuWrapper.cs suggests that 44 >= version <= 99, so it should be fine I guess.

Environment

MacOS 15.5
dotnet 9.0
icu.net 3.0.1
icu 76.1

[lyonsil]

@rgn The ICU libraries must be somewhere in the path for the OS loader to find them. Here is what we did in another project to install these libraries as part of a GitHub workflow. We had problems initially with homebrew, but macports worked OK. But any way to get the libraries properly installed into your path will do.

[rgn]

Thank you @lyonsil for that link. I also used port to install icu.

I applied all the steps in the workflow, as I was not aware of ld64 and the loader paths.
Unfortunately my issue still persists, even when restarting my shell session.

Any tips what steps to take to debug it further?

[lyonsil]

@rgn I believe if you look at trace logging, there should be some more output regarding why loading failed. We log to stdout, so we add the following early in our process start-up.

        var listener = new ConsoleTraceListener { TraceOutputOptions = TraceOptions.DateTime };
        Trace.Listeners.Clear();
        Trace.Listeners.Add(listener);
        Trace.AutoFlush = true;

[rgn]

Okay, it's at least libicui18n that produces my issue.

System.IO.FileLoadException: Can't load ICU library (version 0)
File name: 'icui18n'
   at Icu.NativeMethods.LoadIcuLibrary(String libraryName)
   at Icu.NativeMethods.get_IcuI18NLibHandle()
   at Icu.NativeMethods.utrans_openU(String id, UTransDirection dir, String rules, ParseError& parseError, ErrorCode& status)
   at Icu.Transliterator.CreateInstance(String id, UTransDirection dir, String rules)

So I digged into it. In general this, and the other libraries, exists.

➜  ls -l /opt/local/lib
-rwxr-xr-x@ 1 root  admin  63999400 Mar  4 09:24 libicudata.76.1.dylib
lrwxr-xr-x@ 1 root  admin        21 Mar  4 09:24 libicudata.76.dylib -> libicudata.76.1.dylib
-rwxr-xr-x@ 1 root  admin  63705232 Mar  4 09:24 libicudata.a
lrwxr-xr-x@ 1 root  admin        21 Mar  4 09:24 libicudata.dylib -> libicudata.76.1.dylib
-rwxr-xr-x@ 1 root  wheel   6175360 Jun 26 17:03 libicui18n.76.1.dylib
lrwxr-xr-x@ 1 root  admin        21 Mar  4 09:24 libicui18n.76.dylib -> libicui18n.76.1.dylib
-rwxr-xr-x@ 1 root  admin  11178680 Mar  4 09:24 libicui18n.a
lrwxr-xr-x@ 1 root  admin        21 Mar  4 09:24 libicui18n.dylib -> libicui18n.76.1.dylib
-rwxr-xr-x@ 1 root  wheel    164992 Jun 26 17:03 libicuio.76.1.dylib
lrwxr-xr-x@ 1 root  admin        19 Mar  4 09:24 libicuio.76.dylib -> libicuio.76.1.dylib
-rwxr-xr-x@ 1 root  admin    136624 Mar  4 09:24 libicuio.a
lrwxr-xr-x@ 1 root  admin        19 Mar  4 09:24 libicuio.dylib -> libicuio.76.1.dylib
-rwxr-xr-x@ 1 root  admin    187216 Mar  4 09:24 libicutest.76.1.dylib
lrwxr-xr-x@ 1 root  admin        21 Mar  4 09:24 libicutest.76.dylib -> libicutest.76.1.dylib
-rwxr-xr-x@ 1 root  admin    167576 Mar  4 09:24 libicutest.a
lrwxr-xr-x@ 1 root  admin        21 Mar  4 09:24 libicutest.dylib -> libicutest.76.1.dylib
-rwxr-xr-x@ 1 root  admin    435224 Mar  4 09:24 libicutu.76.1.dylib
lrwxr-xr-x@ 1 root  admin        19 Mar  4 09:24 libicutu.76.dylib -> libicutu.76.1.dylib
-rwxr-xr-x@ 1 root  admin    538656 Mar  4 09:24 libicutu.a
lrwxr-xr-x@ 1 root  admin        19 Mar  4 09:24 libicutu.dylib -> libicutu.76.1.dylib
-rwxr-xr-x@ 1 root  wheel   3606000 Jun 26 17:03 libicuuc.76.1.dylib
lrwxr-xr-x@ 1 root  admin        19 Mar  4 09:24 libicuuc.76.dylib -> libicuuc.76.1.dylib
-rwxr-xr-x@ 1 root  admin   5647456 Mar  4 09:24 libicuuc.a
lrwxr-xr-x@ 1 root  admin        19 Mar  4 09:24 libicuuc.dylib -> libicuuc.76.1.dylib

So I took a look with dyld_info as described in the workflow.

➜  lib dyld_info -dependents /opt/local/lib/libicui18n.dylib
/opt/local/lib/libicui18n.dylib [x86_64]:
    -linked_dylibs:
        attributes     load path
                       @loader_path/libicuuc.76.dylib
                       @loader_path/libicudata.76.dylib
                       /usr/lib/libSystem.B.dylib
                       /usr/lib/libc++.1.dylib
/opt/local/lib/libicui18n.dylib [arm64]:
    -linked_dylibs:
        attributes     load path
                       @loader_path/libicuuc.76.dylib
                       @loader_path/libicudata.76.dylib
                       /usr/lib/libSystem.B.dylib
                       /usr/lib/libc++.1.dylib

I'm not sure why there is x86_64, but I assume it's fine as there is also arm64. What made me wonder is libSystem.B.dylib and libc++.1.dylib, and I checked for their existence in the given paths. Both do NOT exist. My assumption would be that macports also installes transitive dependencies, but it seems this is not the case.

Running dyld_info for both libraries produced the following message and. Honestly, I do not fully understand them but my guess is that they are provided by the OS, but for another architecture arm64e. I'm quite new to MacOS, so my guess might be wrong.

➜  lib dyld_info -platform /usr/lib/libc++.1.dylib
/usr/lib/libc++.1.dylib [arm64e]:
    -platform:
        platform     minOS      sdk
 zippered(macOS/Catalyst)     15.5      15.5

➜  lib dyld_info -platform /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib [arm64e]:
    -platform:
        platform     minOS      sdk
 zippered(macOS/Catalyst)     15.5      15.5

Thinking about installing libcxx via macports, but I do have to find out which is the right version.
For libSystem.B I was unable to find it at macports. So I guess it's a mac specific lib?