Help with dlopen and friends

Shachar Shemesh wine-devel at
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.

> 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 

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 Shemesh
Open Source integration consultant
Home page & resume -

More information about the wine-devel mailing list