Help with dlopen and friends
wine-devel at shemesh.biz
Thu May 22 16:00:13 CDT 2003
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.
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
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
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.
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
More information about the wine-devel