Re: Neat gtk/gdk-imlib pain
Jason Gunthorpe <jgg@ualberta.ca> writes:
> On 1 Feb 1999, Jim Pick wrote:
>
> > > And note that it links to libglib twice. Turns out this is because there
> > > is two 'gdk-imlib1' packages with the same soname but linked against
> > > different versions of glib! By my count we have 72 different package that
> > > depend on gdk-imlib1..
> >
> > I made the same mistable on my first cut of the Gnome packages. It's important that
> > the higher level dependencies (ie. Gnome, WindowMaker, Enlightenment) use the exact
> > same libraries when building as the libraries they depend upon (ie. imlib, gtk, glib,
> > libjpeg, giflib, libtiff, etc.).
>
> Ah but the problem is much more insideous than that! This wmaker-conf was
> from slink, it was never linked against any of these new libraries. The
> problem lies in the library interdependencies.
I agree that it is insideous.
> libgdk-imlib1 in slink did not seem to depend on any glib, in potato it
> depends on a new and incompatible glib from potato BUT the soname was not
> changed. So the instant you install this new libgdk-imlib1 ~40 apps from
> slink silently stop working!
Actually, if you look again, you will see that the soname is not the
problem.
Wakko{jgg}~/work/apt#ldd `which wmakerconf `
libgdk_imlib.so.1 => /usr/lib/libgdk_imlib.so.1 (0x4000f000)
libgtk.so.1 => /usr/lib/libgtk.so.1 (0x40031000)
libgdk.so.1 => /usr/lib/libgdk.so.1 (0x400b3000)
libglib.so.1 => /usr/lib/libglib.so.1 (0x400cf000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x400da000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400e2000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400ee000)
libm.so.6 => /lib/libm.so.6 (0x40191000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x401aa000)
libtiff.so.3 => /usr/lib/libtiff.so.3 (0x401d4000)
libgif.so.3 => /usr/lib/libgif.so.3 (0x4020a000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x40211000)
libz.so.1 => /usr/lib/libz.so.1 (0x4023e000)
libPropList.so.0 => /usr/lib/libPropList.so.0 (0x4024d000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40258000)
libc.so.6 => /lib/libc.so.6 (0x4025e000)
libgmodule-1.1.so.13 => /usr/lib/libgmodule-1.1.so.13 (0x40303000)
libglib-1.1.so.13 => /usr/lib/libglib-1.1.so.13 (0x40306000)
libdl.so.2 => /lib/libdl.so.2 (0x40328000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
In fact, imlib is only being pulled in once. The problem is that glib is
being pulled in twice (from libraries/binaries that were linked with
different versions). These two versions of glib are incompatible, but
they define the same symbols. The dynamic linker is just going to link
to whichever symbol it finds first (somewhat random).
The is a clean solution for this BTW - in glibc 2.1, H.J. Lu has added
support for symbol versioning.
Until we switch to glibc 2.1, and the upstream libraries add support
for versioned symbols, this is going to be a huge problem for
libraries with unstable APIs like glib, gtk and imlib.
In the meantime, we'll just have to suffer with compatibility problems
between slink and potato. :-(
> > Does anybody have an idea about how to devise a lintian check for this
> > problem? I can think of some crude solutions, but nothing really clean.
>
> Lintian will not help this, the damage has already be done - the best you
> can do is change gdk-imlib1 to gdk-imlib1.1 and recompile all your new
> packages and be vigilant to never do this again.
And we'd have to renumber the SONAME as well (or add a conflicts,
gross). Renumbering the SONAME introduces binary incompatibility
between us and other distributions - causing grief for Dale Scheetz,
who's working with the LSB on SONAME incompatibilities.
We'd have to do that for every single library that uses an
incompatible base library in potato than what is in slink. Basically,
anything that depends on the 1.1.x (unstable) versions of glib and
gtk, and imlib too.
I'm not sure that it is worth the effort. We shouldn't be
guaranteeing that applications that depend upon unstable libraries
(ie. libglib1.1.x, libglib1.1.x, etc.) will be easily upgradeable.
We can do it - but it's an awful lot of work. If we want to guarantee
that Debian packages released into 'stable' (ie. slink) are never
going to break - perhaps we shouldn't be releasing things that use
libglib1.1.x and libgkt1.1.x - which are part of the development
branch.
My hope is that by the time potato is released, we'll have moved to
glibc 2.1, and libglib1.2.x and libgtk1.2.x. So there shouldn't be an
upgrade problem at that time.
> Oh, the other alternative would be to make gdk-imlib1 in potato conflict
> with the old gdk that it used to use. That might solve this particular
> instance.
I don't like conflicts. Renaming the library makes more sense. But
it's going to be a lot easier to just ignore the problem - and
convince people not to mix slink and potato. The problem is only
going to get worse in a few weeks when we go to glibc2.1 anyways.
Cheers,
- Jim
Reply to: