On Tue, 2010-06-15 at 09:36 -0400, Behdad Esfahbod wrote: > On 06/15/2010 09:27 AM, Josselin Mouette wrote: > > Le mardi 15 juin 2010 à 08:21 -0400, Behdad Esfahbod a écrit : > >> So, my application uses libraries A and B. It takes a GtkWidget from A, and > >> passes it to a function in B. If A links against gtk-2.0 and B links against > >> gtk-3.0, tell me exactly how does symbol versioning address this? > > > > It doesn’t, of course. It will not magically solve all coinstallability > > problems, just a subset of them. As soon as the application exposes > > widgets from both libraries, you’re pretty much doomed. > > So, which problems *does* it solve? (except for inferring minimum version of > the library required at runtime) > > Isn't GTK+ by nature designed such that all widgets eventually are painted by > on version of the library, and hence simply no way to have two in process > without passing structs from one to the other? > > Plus, what would you do to glib's type system? Only one of the Gtk's can add > the gtype "GtkWidget". Which means, it wouldn't work even if not passing > structs from one version to the other... > As far as I understand it helps with the 'hidden' dependencies. I.e. if package A depends on B which depends on D in version 1.0 and A depends on C which depends on D in version 2.0 but B and C does not expose D interface. If D is libpng B may be gdk and C may be imagemagic. Both links against the same library (D) however both do not expose the ABI and hence it do not clash. In general it should help (I believe) if A does not depend directly on D (not only in terms of linking symbols) - I guess the in gtk+ it won't help but there may be some cases when it helps with glib. However please correct me if I'm wrong. Regards
Attachment:
signature.asc
Description: This is a digitally signed message part