From: Damyan I. <dm...@de...> - 2007-10-31 21:10:43
|
-=| Enrico Weigelt, Wed, Oct 31, 2007 at 05:56:20PM +0100 |=- > * Damyan Ivanov <dm...@de...> schrieb: > > But there will be none in /usr/lib. libicu.so.3.0 is not part of > > any debian package. And if user hand-installs ICU 3.0 in /usr/lib, > > then I guess everything will be OK anyway (same ICU version). > > The problem isn't dynamic linking (at runtime), but starting and > compile time: you can't easily guarantee that the executables are > linked against the old libicu version. > > AFAIK, if you're telling the linker "-lfoo", it will try to find > libfoo.so, which normally points to the most recent version and most > likely exists in /usr/lib if the normal icu package is installed. In debian, libicu.so is not in the "normal" libicuXY package. It is in libicu-dev package that *can* be guaranteed to not be installed when building firebird, bu declaring a Build-Conflicts relation. > I don't see that fb project should be responsible for hacking > around bad icu code again and again and again. > Instead I can imagine to do an clean fork and do it right. Enrico, breaking ABI is allowed when soname is changed too. The problem we have is caused not by hidden ABI breakage, but of the fact that different ICU versions (sonames) behave differently with regard to collation keys (and me being unaware of that fact and building firebird 2.0 with icu 3.6). -- dam JabberID: da...@ja... |