Re: gtk+2 upgrade issue

On Wed, 2006-09-06 at 17:33 -0400, Daniel Macks wrote:
> I'm a bit confused about upgrading gtk+ on some machines I manage
> (fully manually built from source), especially with respect to the
> cairo back-end. I currently have have gtk+2 2.6.10 (no cairo) and a
> boatload of gnome libs built on top of it, and various apps that use
> those libs, and my users have privately built who-knows-what linking
> against all that. I want to upgrade to the latest'n'greatest
> cairo-enabled gtk+2 and pango, but want to minimize breakage or
> mandatory recompiling or upgrading of other things during this
> process. Can I "just" upgrade those libs?
> I figured "same soname, I can just upgrade the lib, no problem", but
> got a bit scared/confused while reading:
> So just to clarify: will I get runtime breakage for things linked
> against the old one (new gtk+2 trying to pass cairo objects up to old
> libs that don't know how to handle them)?

What that thread is discussing is 
compile-against-new-gtk-run-against-old-gtk, something we don't support,
have never supported, and will likely never support.

Doesn't sound relevant to your situation.
						- Owen

(This question should be on gtk-list, it is not about the development
of GTK+ itself.)

> What happens if, given a linkage chain foo -> libbar -> libqux ->
> libgtk+2, I upgrade libgtk+2 and then rebuild libbar (the same old
> version I had)? Will there be any cairo objects or incompatible opaque
> datatypes being passed to un-rebuilt libs? I'm trying to avoid forcing
> a cascade of recompiling on users who have things that are already
> running (and are satisfied with the older versions), and *really*
> trying to avoid a nightmare of figuring out what order to do rebuilds
> or other package upgrades.
> dan

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]