Re: Neat gtk/gdk-imlib pain
On 1 Feb 1999, Jim Pick wrote:
> > > 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).
It takes 3 entities (libraries/programs whatever) where one has been
changed with 'updated' dependencies.
> Because wmakerconf was compiled with the old glib, and the new imlib
> brings in the new glib, and there are some incompatibilities, it
> breaks.
More specificly wmaker conf was compiled with the stable glib, and the
stable imlib. The new imlib was compiled with the unstable glib and hence
wmakerconf, glib and imlib form a triangle of pain :>
> 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.
Exactly what I mentioned during the libtool thread, however that doesn't
seem to be important. Ideally we could have a /usr/lib/gnome-compat dir
<lol> but it seems our dynamic linker isn't smart enough to handle that
for anything but the libc case (right??)
> 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.
With the huge interlinking mess of constantly breaking/changing libraries
that is gnome/gtk the pain will be huge. I actually mentioned that I
expected this problem with gnome/gtk in the libtool thread.
> > > 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.
I mean gnome/gtk/imlib/whatever-todays-library-is. If glib, gtk, gnome,
imlib, etc used versioned symbols then yes you -might- advoid this.
-HOWEVER- my understanding how how versioned symbols would need to be
implemented would make this pretty much impossible for a large portion of
the libraries that compose gnome. (ie you have to provide the orignal
symbol and somehow interweave it into the new library structure)
> 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).
There are currently 72 things that link against imlib. I suspect that
about half were linked with the 'old' imlib and half with the 'new' imlib.
So no matter what system you have half your apps will magically break
without warning or explanation. To make things worse the packages using
the 'new' imlib do not have a versioned dependency on the new imlib
(though it got installed so something must..)
> > For the moment I suggest the conflicts because it can easially be
> > done..
>
> It wouldn't hurt. Or would it? My brain hurts.
It might not fix the whole problem because it is likely you can use 'new'
apps with the 'old' imlib and still have it not work! That you will have
to study more, because when I installed gnome-apt I did get this new imlib
but I don't know what caused it to be brought in.
> 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.
Ah, umm. I asked Joel about this I forget what the deal with that is..
Jason
Reply to: