[Development] Proposed solution to the ICU problem

Björn Breitmeyer bjoern.breitmeyer at kdab.com
Tue Jul 31 14:25:26 CEST 2012


Hi,

i am a bit confused now, will ICU be hard dependency on 5.0 instead of 5.1?
As i already mentioned we are having problems with a hard ICU dependency
for WindowsCE as its not supported by the ICU buildsystem.

Will ICU become  part of the 3rdparty repo with a more cross platform friendly 
buildsystem? As of know its a huge linux configure script and i was unable to 
even generate my own visual studio solution with the proposed cygwin setup.
The only way to get a working windows build is use the shipped sln file which
requires a new visual studio.

In general i don't know  how open the ICU guys are to new platforms. But i see 
this as a larger problem for porting qt to a non unix platform.

I get the reason why ICU is a good idea for supported platforms, but is there 
a reason to enforce it on all platforms?

Best regards
Björn Breitmeyer

Am Dienstag, 31. Juli 2012, 14:00:10 schrieb 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.
-- 
Björn Breitmeyer | bjoern.breitmeyer at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Germany: +49-30-521325470, Sweden (HQ): +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3008 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120731/8192c4b1/attachment.bin>


More information about the Development mailing list