MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17266.36914.934378.399914 at karryall.dnsalias.org>
Date: Thu, 10 Nov 2005 01:11:30 +0100
From: Olivier Andrieu <adrieu at ijm.jussieu.fr>
To: Robert Roessler <robert at rftp.com>
Cc: LablGTK List <lablgtk at math.nagoya-u.ac.jp>
Subject: Re: GTK versions/versioning
In-Reply-To: <436AD01F.5070203 at rftp.com>
References: <436AD01F.5070203 at rftp.com>

Hi, 

[Sorry for the late reply, my email was broken for a couple of weeks]

The GNOME project has some pretty strict rules concerning ABI and API:
 http://developer.gnome.org/dotplan/api_rules.html

 Robert Roessler [Thursday 3 November 2005] :
 >
 > If I have a so/dll of LablGTK built against, say, GTK 2.6.8, what 
 > *binary* compatibility should I expect?
 > 
 > For instance, if the GTK 2.6.9 *binary* package has been installed on 
 > a system, is the LablGTK code expected to run without problem? 

Yes (any GTK+ for that matter)

 > What if GTK 2.8.6 binaries are present?

Same thing

 > Going the other direction (although not as interesting), what if, say, 
 > GTK 2.6.2 binaries are all that is present?

That should work too. All 2.6.x versions (should) have the exact same
API/ABI. The differences are bugfixes in the behaviour of functions
for instance.

 >  Or GTK 2.4.14?

It's a bit different: it depends on what version the lablgtk code was
compiled with. First, of course, if your code uses functions or
widgets added in GTK 2.6 there's no hope it will work with GTK 2.4.

But even if your lablgtk code doesn't use 2.6 features but was
compiled against a GTK 2.6, linking will most probably fail with a GTK
2.4. There's a workaround for this case: you need to define
-DDISABLE_GTK26 when compiling lablgtk. I simply add it to this line
in src/Makefile :
  GTKCFLAGS += -DLOG_DOMAIN=\"LablGTK\"
(btw, this you should be G_LOG_DOMAIN, I'll change that)

With this flag, GTK 2.6 specific code is replaced by stub code that
simply raises an exception.

-- 
   Olivier