On Thu, 2003-05-22 at 19:43, Shachar Shemesh wrote:
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
Suckage. I know a few libs do this, libdb springs to mind. It's basically poor mans GNU symbol versioning but in a way that doesn't require you to use glibc or the gnu toolchain. Unfortunately, it sucks as a result.
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.
This is intentional. It's most often used for libs that have no intention of bumping the soname when they break the ABI, instead the individual function is renamed. So, depending on whether the source is compatible or not, you might not even be able to recompile easily.... the idea is similar to that of glibc.
- Static link the library - now that will actually work. It is
equivalent to 2 without the maintanance headache.
Depending on how widely used it is, this may be an acceptable option. I don't really understand why you can't use the official header files thought that presumably do this name mangling.
If this is actually the scheme they use, don't worry about future versions not working - all future versions will have that function, they may have other versions with different end tags though.
Opinions and thoughts, please.
Opinion: symbol versioning is nice in theory, but a PITA in real life. Especially since it can be hard to "wind back the clock" and get an earlier set of symbol versions, in fact, ld doesn't support this at all. In autopackage we use a variety of nasty hacks to get around it. Soname versioning generally works just as well, at least for small libs. But looks like you're stuck anyway :(
thanks -mike