Re: change of ABI in Gtk+ 2.10 on Win32

[Tor Lillqvist <tml iki fi>]

Arnaud Charlet writes:
 > #ifdef G_OS_WIN32
 > /* Reserve old names for DLL ABI backward compatibility */
 > #define gtk_accel_map_load gtk_accel_map_load_utf8
 > #define gtk_accel_map_save gtk_accel_map_save_utf8
 > #endif

This was done already in GLib and GTK+ 2.8. No new ones were
introduced in 2.10, as far as I can recall.

As the comment says, the DLL ABI is *not* broken. On the contrary, the
whole point of these acrobatics is to keep DLL ABI stable.

The old symbols with their old semantics (take system codepage
pathnames) are still present in the DLLs. It's only code that is built
against 2.8 or newer headers that will use the new versions of the
functions that take UTF-8 pathnames and have _utf8 tacked on to their
names.

 > Which causes a huge number of undefined symbols when binding Gtk+ in another
 > language (in my case, GtkAda).

The old functions are not mentioned in the import library on purpose,
to avoid accidentally using them when building against new headers.

If you have your own Ada versions of the headers, you need to do a
similar #define trick in them. (Or whatever the equivalent Ada thing
is.) Or, you can continue building against your old pre-2.8 style
headers and link against a pre-2.8 import library, but still *run*
against the 2.10 DLL.

 > Where are the old symbols (without _utf8) defined ?

They are in the DLL, but not in the import libraries as distributed
in my packages on ftp.gtk.org.

 > Can we do something to improve the situation ?

If you like, you can generate own import libraries that include all
the exported symbols.

But please note that if you continue to use the non-UTF8 API, your
code will not work for pathnames that contain characters not
expressable in the system codepage. (Like for instance Greek or
Cyrillic in a Western European or American Windows installation, or
various uncommon Chinese characters in CJK installations.)

Any *new* API that take pathnames that has been introduced in 2.8 or
later *always* takes UTF-8 pathnames. It doesn't need any
backward-compatibility versions that would take system codepage names,
as it didn't exist in those times when GLib and GTK+ used system
codepage pathnames on Win32.

If you in GtkAda deliberately choose to bind to the backward
compatibility version of for instance g_file_test() that takes a
system codepage pathname, but still also provide a binding for new API
like g_mkdir_with_parents() that takes a UTF-8 pathname, you have a
very confusing situation.

--tml