From: Adriano d. S. F. <adr...@gm...> - 2010-11-09 17:13:01
|
On 09/11/2010 06:00, Alex Peshkoff wrote: > On 11/08/10 21:29, Adriano dos Santos Fernandes wrote: >> On 08/11/2010 16:19, Alex Peshkoff wrote: >>> Done, though this is work in progress. I plan to make firebird always >>> load ICU dynamically (though need in devel package when building it will >>> anyway remain). >> Why? Currently only essential functions are statically bind. Collations >> are already loaded dynamically. >> >> I see no need to use essential functions with dlopen/dlsym, if that's >> what you mean. > Adriano, there is only one reason for this - avoid dependency of binary > packages on SF from specific ICU version. Behavior of essential > functions does not vary from version to version, but SOnames of > libraries do change. Therefore if we build binaries with ICU X.Y, people > that have installed any other version will not be able to use that > binaries without installing used by us ICU version. And we have silly > case - code, required for us, is present in the system, but we can't use > it due to soname restriction. I understand that per-distro packages do > not have this problem - required ICU is sooner of all already installed > or at least that package has required dependencies. But I wish to have > generic binaries also as good as possible. > Although the distro people are using their standard ICU already, I do not think this is good idea for our provided binaries. It just makes things more complex. 1) Windows has no ICU. We can package one, but if we remove from our sources we make build complex. 2) The great thing of FDB files was that one can transport and use them directly in similar architectures. But each Firebird installation using a different ICU versions, that breaks. Nbackup backups will not work and one would need gbak, which is not good for big databases. > Certainly, we can simply add ICU, used to build packages, to them. But > this is, first, not elegant, and next - requires from us to fix binaries > in case of some issues with ICU. Suppose you know better than others > that ICU does have issues sometimes ;-) With ICU-version-independent > packages people upgrade ICU - and this requires absolutely no activity > from us. > > BTW, do you have an idea - how to define version of ICU after library is > loaded? I need it to know exact names (like ucnv_open_X_Y) of exported > functions. Certainly, in the worst case brute force search is possible, > but may be something better can be done? Look at u_getVersion. Adriano |