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 far as this specific patch goes, Stuart makes a *ways* more convincing argument, well thought out (which is not surprising, cheers Stuart), namely that since some dependent components of qt will link against icu4c, during complicated updates, we will end up with two distinct versions of icu4c loaded... all bets are off anyways. So, based on sthen@'s comment, I'm willing to admit we're in deep shit, and that your patch doesn't worsen the problem, so yep, it can go in. But it's NOT NOT NOT NOT NOT because qt properly checks the libicu4n ABI. It doesn't. It's because we're fucked already. So it can't get much worse.
