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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
