Backwards compatibility issues with GDK 2.4

[Mike Hearn <mike navi cx>]

Hi,

For GDK 2.4 a patch [1] was integrated which effectively rewrites code to
give it an implicit dependency on GDK 2.4 only symbols.

This is problematic, because it means that developers who upgrade to GTK
2.4 for themselves, but do not wish to give their software a
hard dependency on 2.4 just yet can easily do so without even being aware
of it. In other words users can be forced into upgrading GTK if they wish
to use binaries compiled by somebody else on a 2.4 system, even if that
software has explicitly avoided functions marked as "Since 2.4".

This is the same sort of problem glibc causes with symbol
versions[2] - people are unaware that various macros are being redefined
underneath them to give them new features but at the same time
dependencies on the latest software they may not want.

There are a few possible solutions to this problem:

1) Require the developer to add a #define before including gdk/gdk.h to
enable the usage of the new thread functions. If it is not defined, the
new gdk_threads_set_lock_function is not available, and
GDK_THREADS_ENTER/LEAVE work the same way as before, referencing the
deprecated gdk_threads_mutex variable. If it is the new codepaths are
switched on. 

This causes an API but not ABI break.



2) Mark gdk_threads_lock and gdk_threads_unlock as weak symbols in the GDK
library on platforms which support this feature. GDK_THREADS_ENTER/LEAVE
can then be redefined to look like this:

if (gdk_threads_lock) 
	(*gdk_threads_lock)();
else if (gdk_threads_mutex)
	g_mutex_lock(gdk_threads_mutex);

In other words, when running against GTK 2.2 or 2.0, gdk_threads_lock will
be set to NULL by the dynamic linker rather than causing a startup failure
the users binary will fall back to trying gdk_threads_mutex. If
gdk_threads_set_lock_functions is in fact required by the app, it will
still fail to link as normal.

It's late but I think solution 2 would work with a minimum of pain, and
could be added to 2.4.1 without breaking anything, ie in time for the next
round of distro upgrades. 

Thoughts? Please don't just say "the user should just recompile the app"
or "they should use an RPM built for their distribution" - while this is
one solution it's not the best from a usability perspective.

thanks -mike

[1]http://mail.gnome.org/archives/gtk-devel-list/2003-December/msg00019.html
[2]see the redefinition of the ctype macros in the move to thread-local
locale models.