[haiku-commits] Re: r42638 - in haiku/trunk: build/jam headers/os/locale headers/private/locale src/kits/locale src/preferences/time ...
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 26 Aug 2011 16:38:59 +0200
On 2011-08-26 at 13:25:52 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
> Philippe Houdoin<philippe.houdoin@xxxxxxxxx> wrote:
> > > Note: all software using ICU (like WebPositive) needs to be rebuilt!
> > Which leads to the question: why?
> > Does the ICU's API not backward compatible ?
>
> As Oliver noted, ICU used to use a version specific namespace for its
> exported functions.
> Since WebPositive is using ICU directly, it needs to be rebuilt, obviously.
> Oliver now changed this to let it export a stable namespace instead which
> causes less updates on our side when we update to a new ICU version. I'm
> not sure if that's a good idea for third party software, but those will
> probably have other means to denote their version requirements; it might
> just get messy when there are several versions around that all use the ICU
> namespace (i.e. if they use their own ICU version, but link against
> liblocale.so). Oliver may shed some light on how he intends to solve this
> issue.
Hm, that's a good point, I didn't think of this problem at all :-\
One solution would be to go back to building ICU with the fully qualified
namespace and then introduce a define in a topmost LocaleKit header that
maps ICU_NAMESPACE to the current one (i.e. icu_48 at the moment).
Alternatively, we could ban the ICU namespace completely from our public
headers, which would require several LocaleKit classes to hide their
implementation completely. This is a good idea in general, but at the cost
of one more allocation ...
But no matter which way we decide, using two different versions of ICU in an
application is likely to be problematic anyway, I'm afraid: even with
separate namespaces for C++, ICU uses a couple of C APIs whose name are not
version-specific, so symbol preemption will cause havoc one way or the
other. And using dlopen() on liblocale.so or those ICU-libs is not going to
be fun :-\
cheers,
Oliver
Other related posts:
