On Tue, Oct 09, 2012 at 10:45:25AM +0100, Stuart Henderson wrote: > On 2012/10/09 09:56, Federico Schwindt wrote: > > > [..] > > > I tested it and then removed the diff from my ports tree... I need > > > this patch to go in because kdelibs 4.9.2 is complaining about the > > > same thing i.e Cannot load library icui18n > > > > > > will somebody commit this after approval? marc? > > > > new (untested yet) diff attached. this should be OK with espie. > > > > f.- > > Can't we just make it a LIB_DEPENDS/WANTLIB (will show as "Extra" but that's > ok) > and use the original patch to just remove the version? qt4 already depends on > gstreamer-base which depends on pango which depends on icu4c, so in reality > there's no new dependency in this case, it just forces pkg_add to update > things when necessary.
No, because qt4 won't be really tied to the icu4c version. Consider: install icu4c with shared lib .so.N.0 install qt4 compiled for icu4 shared lib .so.N.0 update icu4 to shared libs .so.N+1.0 which is not guaranteed to be compatible with .so.N.0 (in fact, a major bump means it's GUARANTEED not to be compatible) With the dependency tree you outline, .so.N.0 will still be around as a .libs-icu4c But qt4 dynamically loads things! If you don't tie the version number down, it will load .so.N+1.0... But it should *still* try to load .so.N.0, not .so.N+1.0 Of course, you might get lucky and not run into the incompatible behavior (as qt4 probably doesn't use the whole icu4c ABI), but the whole POINT of major version numbers is to prevent incompatible ABI from being called. And we have *no finer granularity* than the whole shared object. Again, we may get lucky and just call a few functions that haven't changed... but if we start doing that, we can stop having shared library major numbers altogether!!! See why this is wrong ?
