Re: Versioned symbols for 3.0?

[Josselin Mouette <joss debian org>]

Le mardi 18 mai 2010 à 12:32 -0400, Behdad Esfahbod a écrit :
> > As for not wanting to use versioned symbols, could you provide more
> > information why such a decision was made?
> 
> I can't speak for Matthias, but I guess it's because no one pointed out what
> currently-existing problem exactly it's trying to solve.

The use case that Patryk mentioned is a bit RPM-specific. As Emilio
explained, DEB-based distros have other mechanisms to cope with this,
and AFAIK Gentoo isn’t really affected by versioning issues.

The use case for which we need symbol versioning the most often is the
following:
      * libfoo depends on libbar
      * program superfoo depends on both libfoo and libbar
      * libbar is available with two sonames: libbar.so.1 and
        libbar.so.2

In this case, if you have a libfoo that still depends on libbar.so.1
while superfoo depends on libbar.so.2 (or the opposite) you will get
symbols from both libbar.so.1 and libbar.so.2 in the same symbol table,
and they will be loaded regardless of their actual ABI.

If you have different symbol versions for both libbar.so.1 and
libbar.so.2, they can be both loaded and used by the same process, and
the problem remains hidden.

This is the use case that would make such a feature very useful, not for
glib (if it’s not expected to change soname), but for GTK+ (both 2.x and
3.x). I don’t expect many libraries that link against one GTK+ version
to be usable by a program linking to the other GTK+ version, but
unfortunately it is very likely to happen anyway - for stuff using Gdk
and Gdk_pixbuf, or for some plugins.

Cheers,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-    […] I will see what I can do for you.”  -- Jörg Schilling