On Tue, Oct 09, 2012 at 12:14:58PM +0200, David Coppa wrote:
> On Tue, Oct 9, 2012 at 12:10 PM, Marc Espie <es...@nerim.net> wrote:
> > 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 ?
>
> I meant, following your approach, that gtk+2 and cups, which
> previously got fixed by just
> removing the version number, now need the right major number.
> Is this correct?
Correct
