Eric Pouech wrote:
I'm going to static link. It seems like the only sensible solution. Since I have 2.1, and Eric has 2.6, there is little hope of doing dynamic linking and hoping for it to work.
note that it's not installed by my distro (I dl:ed it for tests)
That may be a reason not to use ICU, but is irrelevant for the question of whether static/dynamic linking is in order.
so, it may also be very likely that view distro actually ship it
I did not find it in RPMFIND. Debian unstable has it. The package's site only carry sources. This is a tough one, and no doubt about it.
moreover, it seems that the packager of the lib can turn off the symbol mangling so, we're not even sure the mangling will always be present
All the more reason to static link it.
A+
The static link question seems simple enough. I know that Mozilla uses ICU, and I think OpenOffice does too. Both of them don't have a runtime dependancy on it (or else it would be available for redhat, right?). This means they either static link it or imported the sources into their app.
As for the library itself, it boils down to this. It's a horrible library packaging wise, but it's the only one that has what I need, or even likely to have what I need in the foreseeable future. I have been holding off linking with FriBiDi hoping that Behdad, or anyone else, will put in the new interface (that will also let me implement some of GetCharacterProperties more obscure features). That is not likely to happen. I suspect FriBidi has fallen off the end of the earth. It does not implement mirroring, nor does it implement Arabic Shaping (wierd, considering that the maintainer is from Iran). It only supports UCS-4.
Also - like I told Mike H on IRC, static linking ICU will mean that we don't have to remove a dependancy from the Wine binary if FriBiDi ever catches up.
ICU implements both mirroring and shaping. It supports UTF-16, including not reordering the surrogates inside RTL runs (a tough one). It has already been updated for Unicode 4.0 (not the Debian version, of course, but the version you downloaded is). This is meaningless for BiDi (there was no change), but does indicate that the library is alive.
The compile time dependancy is nothing new. It will be there whether I static link or dynamic, and for whichever library I use. The fact that this is an uncommon library, coupled with the fact that I'm going to make it an optional compile time dependancy, means that there is a high chance that the Wine packagers will neglect to download it before building Wine packages. This is a bummer, as the resulting Wine will not support BiDi, but should have no other side effect.
I'm sure my head will be chopped by my fellow Israeli Wine users when they find out, but I'm hoping to divert their wrath torwards the packagers. It does mean that a visible "it is recommended that you have this installed on your system while building Wine packages" document is a desireable thing (like I said on the meeting). I'm willing to start one, but I don't know all of them.
Shachar