libicu is not ABI compatible because of --enable-renaming usage

[Harald Fernengel]

Binary package hint: libicu42

Currently, libicu is built with symbol renaming, which leads to a rename of
every symbol, e.g. ucol_strcoll becomes ucol_strcoll_4_2. Check with "nm -CD
libicui18n.so.42" - all public symbols have the _4_2 suffix.

This means that on the next system upgrade (e.g. to libicu 4.4), all
applications linking to libicu will need to be rebuilt.

For reference, see
http://userguide.icu-project.org/design#TOC-ICU-Binary-Compatibility:-Using-ICU

Quoting:

========
To enable release-to-release binary compatibility, ICU must be built with
--disable-renaming, and applications must be built using the headers and
libraries that resulted from the –-disable-renaming ICU build
========

I suggest to follow ICU's suggestion to build libicu with --disable-renaming, so the library can be
upgraded without breaking binary compatibility.

[Steven R. Loomis (srl-icu-project)]

Note that ICU is ABI compatible to the same Major+Minor. SO in other words, if the dependency is on "icu 4 . 4" that can be satisfied by ICU 4.4.0, 4.4.1, 4.4.2 - those are compatible. If another application (or library) depended on ICU 4.6, they can peacefully coexist in the same address space.

One benefit of disabling renaming in the OS is that if an app wants a certain ICU version, it can enable renaming and link with a renamed ICU, ignoring the disabled-renaming symbols in the OS even if they are linked.

MacOSX (Apple) disables renaming in their ICU build for the OS, i believe AIX does also.

So to sum: if the package name is something like "icu44" and "icu46" then renaming is good, apps can depend on one or the other or both. If the package name is just "icu" version 4.4, then disable renaming.

Regards,
Steven (ICU)

[Harald Fernengel (harry-bnro)]

Thanks Steven for the information.

Please see the whole thing from an application developer's point of view. If I want to ship a binary that targets a lot of Ubuntu versions, I need to choose an ICU version, e.g. 4.2, then make my package depend on ICU versions between 4.2.0 and 4.2.99, since 4.3/4.4 will be binary incompatible. That means that I force installation of older ICU versions, although technically, I just need any ICU version >= 4.2.0 (since I only use the stable API).

Now, on Mac OS X or AIX this might not matter, but on netbooks or embedded devices, it doesn't make sense to ship several ICU versions in parallel. Imagine a use case where the user installs three binaries, which all use ICU in different versions - you'll have all three libraries paged into memory at run time, plus wasted a lot of space on the memory card.

All other libraries in Ubuntu are identified by their major number, so I can just depend on libfoo >= 2.x, and don't worry what the x is as long as it satisfies my minimal dependency.

[Steven R. Loomis (srl-icu-project)]

Harald,
 I do see it from the developer's point of view. That's why this is a selectable option within ICU.
 It's a decision that the packager (Ubuntu, in this case) needs to make. Disabling renaming makes more sense for an OS level packager. However, for a complex application, it may not make as much sense.

[Harald Fernengel (harry-bnro)]

Steven,

that's my whole point - Ubuntu, as an OS, should disable renaming to keel the OS ABI stable.

Could the package manager take up the task?

Thanks,
Harald

[Dan Kegel (dank)]

This is discussed in the source package's debian/README.source, which says

... please see the thread about this topic on the icu-design list ...
 http://sourceforge.net/mailarchive/forum.php?forum_name=icu-design
and find the thread from June 10, 2008 with the subject "debian: use
of --disable-rename and ICU library sonames".

The message in question is
http://sourceforge.net/mailarchive/forum.php?thread_name=20080618182302.2012566511.qww314159%40motoko.argon.local&forum_name=icu-design
and the thread concludes

> Running without renaming, and changing out the version of ICU behind
> installed applications would involve a greater risk of instability.
> The flip side is making available updated locale, language, Unicode &
> data that comes with a new version of the library.
>
> So it's not completely black and white, but I suspect continuing with
> renaming is safest. Let installed binary applications continue to run
> with the ICU version they were built with.
Okay, thank you for your response and for checking my analysis. I'll
continue doing things the way I've been doing them.
--Jay Berkenbilt <ejb@...>

So it's probably safe to say the package maintainer knows about the
situation, has thought carefully about the issue,
is doing this by design, and is not likely to change anything.

[Dimitri John Ledkov (xnox)]

Based on https://bugs.launchpad.net/ubuntu/+source/icu/+bug/675946/comments/5 this is desired behaviour.