[Development] Proposed solution to the ICU problem

[Thiago Macieira]

Quick discussion on IRC happened. This is a summary of the discussion and 
proposal for the SDK.

Situation:

The ICU libraries *do* offer a stable C API, which they say they will maintain 
and keep compatible. However, the library soname changes on every version and 
most distributors enable symbol renaming. That means we cannot depend on the 
stable API.

What's more, ICU may or may not be present on some systems.

On WIndows, it's not present. Therefore, we need to supply our own ICU anyway. 
Any Windows programs will need to ship it and our deployment instructions 
should be adapted to match.

On iOS, it is present but dlopen is not available to applications. Therefore, 
we must link to it anyway (note: I don't know if App Store rules permit that). 
If the ICU versions do change on different iOS versions, then application 
developers will need to create multiple versions of their applications.

For Linux distribution packages, the version of ICU is tightly controlled by 
the distributors. Therefore, linking to it is no problem and should be the 
default. This is also the default for people downloading and building from 
sources.

The problem remains for the Linux and Mac SDKs and for Android. I don't know 
the situation on QNX, but it is either this case or the one above of 
distribution packages.

For the Linux and Mac SDKs, we *can* get away with shipping our own copy of 
ICU, just like it will be done for Windows. For Android, it would be 
preferable if we could dlopen the library. If we have the code to dlopen, 
however, then we could also use it for Linux and Mac SDKs. Unfortunately, due 
to the symbol renaming, soname renaming and the QtWebKit dependency, this 
solution is too much work for 5.0.

Proposal:

We propose then that for the 5.0 SDK packages, we ship our own copy of ICU, in 
all cases. It's already done for Windows. I'd also recommend going further and 
using ICU's own renaming system to insert a "q" in the function names and 
soname so they don't conflict with the system.

As a 5.1 task, we propose investigating the searching+dlopen solution.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120731/40236362/attachment.sig>