Re: Neat gtk/gdk-imlib pain
Jason Gunthorpe <jgg@ualberta.ca> writes:
> On 1 Feb 1999, Jim Pick wrote:
>
> > > 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.
>
> Read the libtool thread. What has been done here is to recompile a library
> against a different set of libraries in an incompatible way without
> changing the soname
Ok. You are correct.
> > 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
>
> The library that does this is imlib according to my investigation.
Actually, it takes two libraries to create the problem (unless something was
compiled wrong).
Use objdump --private-headers and look at the NEEDED field:
$ objdump --private-headers /usr/bin/X11/wmakerconf
NEEDED libgdk_imlib.so.1
NEEDED libgtk.so.1
NEEDED libgdk.so.1
NEEDED libglib.so.1
NEEDED libXi.so.6
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libm.so.6
NEEDED libjpeg.so.62
NEEDED libtiff.so.3
NEEDED libgif.so.3
NEEDED libpng.so.2
NEEDED libz.so.1
NEEDED libPropList.so.0
NEEDED libnsl.so.1
NEEDED libc.so.6
$ objdump --private-headers /usr/lib/gdk_imlib.so.1
NEEDED libgmodule-1.1.so.13
NEEDED libglib-1.1.so.13
NEEDED libdl.so.2
NEEDED libc.so.6
Because wmakerconf was compiled with the old glib, and the new imlib
brings in the new glib, and there are some incompatibilities, it
breaks.
We could change the SONAME to designate the break in compatibility.
But then it wouldn't match upstream. It really isn't the upstream
maintainer's fault that we released one version compiled against
libglib 1.0, and one against libglib 1.1.
We are going to have this problem anytime any of the dependent
libraries of imlib, or gnome change. This is going to be a big
problem for me, I can tell - the gnome libraries depend on so many
different libraries.
> > The is a clean solution for this BTW - in glibc 2.1, H.J. Lu has added
> > support for symbol versioning.
>
> I don't know much about the symbol versioning but I highly doubt that
> using glibc2.1 will have any effect on this problem with gtk.
You mean glib, right? If glib used versioned symbols, the dynamic
linker would be smart enough to link the symbols that use the new APIs
with the newer library - and everything would be happy.
> My understanding is that the library author will have to take
> special steps to make versioned symbols through some magic means..
Yes, the upstream library author would have to assign a version to the
symbols that had changed. It's not too hard - but it may be a problem
for the upstream authors because hardly anybody has switched to glibc
2.1 yet. We'll probably be the first distribution to do it (in
unstable).
Symbol versioning is quite a confusing system, and there isn't much
good documentation for it (outside of the documentation for Solaris).
I've got a PDF file of the Solaris Linker and Libraries guide (which
HJ based his work on) if anybody is interested.
> > 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.
>
> Isn't the slink imlib/gtk1 'stable'? I really don't follow their
> development. If you accept that gtk 1.0.6-2 is a stable library then you
> have to take steps to ensure that installing the unstable libraries do
> not kill the system, it is the only nice thing to do :<
They are using the same scheme as the Linux kernel - odd numbers
designate the unstable development branch.
Anyways, the wmakerconf problem can be fixed for potato by recompiling
wmakerconf for potato with the proper libraries (and recompiling it
every time one of it's dependent libraries breaks compatibility, which
happens almost weekly with gtk/glib 1.1.x).
Should imlib have declared it's incompatiblity? Probably. But it's
going to happen every time a new gtk or glib comes out that breaks
compatiblity.
> > 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.
>
> That is probably a sane idea in of itself.
But it's not a very popular idea. People wanted me to release Gnome
0.30 with slink even though it isn't stable yet. The same thing goes
for all the applications (40+, as you said) that use glib/gtk 1.1.x.
It's difficult to keep these packages up and running when the
libraries they depend upon are under development.
> > > 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.
>
> Well do one or the other, this 'silent breakage' is really nasty and will
> probably generate alot of confused users (already has actually, people
> complain to me that their old gtk apps die when they installed
> gnome-apt!).
I agree it's nasty. I think we are going to need 'slink-unstable'
pretty soon, where people can upload versions of unstable packages
specially compiled for slink. Didn't we used to have a 'bo-unstable'?
> For the moment I suggest the conflicts because it can easially be
> done..
It wouldn't hurt. Or would it? My brain hurts.
> I don't see how glibc2.1 wille effect things at all, it is fully
> compatible with 2.0 there will be no pain aside from any intrinsic
> buggyness it might have.
It might be a problem for slink users that are trying packages out of
unstable, I think. I'm not sure if a glibc 2.1 compiled app will run
on glibc 2.0.
Cheers,
- Jim
Reply to: