FFI C/C++ with dynamic library icu_capi_cdylib

[jlfaucher]

I tested the FFI examples with the dynamic library icu_capi_cdylib.
Same success and failures as with the static library, so looks good.

Q1)
Do I have the same functionalities as with the static lib? All the C/C++ FFI bindings are available?

Q2)
If i'm not wrong, the release v1.0.0 is only delivered as source code. Any plan to deliver the static and dynamic FFI library in the future?

Q3)
I work on a prototype where Unicode services are currently provided by utf8proc and ziglyph.
Both are linked statically, they are small libraries.
Both have services in common, and similar Unicode datas. This redundancy is not a problem, i'm just experimenting and learning.
The next step is to link also with ICU4X.
Given the files sizes I get with the FFI examples, it seems I should link dynamically with ICU4X, to keep my own binaries small.
Or maybe I use wrong options and could reduce more the binaries sizes?
files_sizes.txt

[sffc]

The only difference between the staticlib and the cdylib is that one is for static linking and the other one is for dynamic linking. The cdylib has ABI stability, so you can swap in an ICU4X update in the future and callers should continue to work without having to be re-compiled. With the static lib, you need to re-compile the callers, but the advantage is that you only ship what you use.

The way to get the smallest code sizes is to static-link ICU4X and run it through LTO. You should also build ICU4X with panic=abort for additional savings. See here for an example of the size-optimized ICU4X build over FFI:

https://github.com/unicode-org/icu4x/tree/main/ffi/diplomat/c/examples/fixeddecimal_tiny

It's also fine to ship a cdylib, but by doing so you can't run LTO to optimize for the pieces you need. If you have multiple apps that all need to share the same library, then the cdylib is more likely to make sense.

[jlfaucher]

Thanks!