Help with dlopen and friends

[Shachar Shemesh]

Hi all,

I am trying to add ICU as a soft dependancy of Wine, so I can use it's 
BiDi functions. Unfortunetly, it seems to be using miracolous name mangling.

ubidi.h has:
U_CAPI UBiDi * U_EXPORT2 ubidi_open(void);

however, 'nm -D libicuuc.so.21.0' gives:
00046784 T ubidi_open_2_1

The problem is not just theoretical. When I try to add to configure.ac:
AC_CHECK_LIB(icuuc,ubidi_open,icu_lib=yes)
the resulting program does not compile. It only compiles properly if the 
original header is used (I presume because that's how it knows about the 
name mangling).

My dillema - even if I sort the configure mess out, for example by 
telling it to compile my own program, that uses the proper include, I am 
still not going to be successful in importing the symbol. As it appears 
that the mangling is a simple append of the library version, I can do 
this manually, but then future version stand no chance of working. Even 
if a simple recompile would solve it, the version will need to be 
updated at the import code.

Possible solutions:
1. Use a different library - can be done, but messy. This is the most 
apropriate tool for the job. FriBiDi doesn't have shaping support, so 
Arabic will not work properly.
2. Inline the entire library - huge, and a maintanace headache.
3. Reimplement everything - possible, but seems like a total waste just 
because of a stupid name mangling.
4. Create a hard dependancy - not really an option.
5. Static link the library - now that will actually work. It is 
equivalent to 2 without the maintanance headache.

Opinions and thoughts, please.

             Shachar

-- 
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/