On Tue, Oct 9, 2012 at 2:16 PM, Marc Espie <es...@nerim.net> wrote: > On Tue, Oct 09, 2012 at 02:01:26PM +0100, Federico Schwindt wrote: >> I sent this patch quickly before I left for work so I didn't have time >> to write anything but I'd like to make my stance clear. >> >> I rewrote this patch because espie doesn't believe the original >> approach was correct and he is too busy to do it himself. >> >> I don't specially care about qt4 and I'm a bit annoyed that he's >> particularly picky about this patch when there are 2 others in qt4 >> that do this but for the benefit of other users and in order to remove >> a warning from the only port I use that depends on qt4 I submitted it. >> >> I don't agree with espie. The dlopen approach is quite different than >> linking to a library: a dlopen is always followed by a dlsym. If qt4 >> expects the library to provide certain symbols without checking (which >> btw is not the case in qt4) the code is wrong. >> Having a particular version hardcoded in the qt4 code does not >> guarantee that this version will have the needed symbols, only that >> this particular version was present when qt4 was compiled. >> I think this subtle difference is quite important. qt4 does NOT >> enforce NOR requires a particular version. It's just using 49 because >> that's what's in the icu4c headers, that's all. > > I'm going to put a bit more oil on that fire, because I believe what > you're writing here is wrong, so there HAS TO BE SOME CORRECTION in the > mailing list archives. > > An ABI is *not* a symbol name. (We are NOT using versioned symbols on OpenBSD, > in any case, and versioned symbols are a HUGE can of worms that takes YEARS > to get right with DEADLY CONSEQUENCES when you fuck up). In many, many > cases, a major library bump will happen *without* any visible symbols > changing. Structures that change size *are* a major reason of ABI changes. > > Heck, they are THE main reason for ABI failures. > > And you can open the new library, and you can locate the symbols, and > you will still get fucked. > > Or, hey, when/if we switch time_t to 64 bits, have fun mixing your new > kernel and your old libc... (no symbol change !!! so it must still be right, > right ? Remember that I did handle the big ABI breakage back when we > started implementing wide-chars, and suddenly, FILE* were not FILE* any more > ?) > > As usual, you can't predict the future. It might be this will never happen > with icu4c. If it does, no amount of guessing through dlsyms will save you. > It's what major library numbers are for. > [..]
As much as it pains me to admit it you're right. I looked at the code and was under the impression that qt was not using any of the structures from icu4c but I was wrong. f.-
