GNOME Bugzilla – Bug 151167
Interface deletions from glib.2.0.x to glib.2.4.x
Last modified: 2004-12-22 21:47:04 UTC
Because of our concern about upward compatibility in Solaris, and the inclusion of GNOME within Solaris as our desktop environment these days, a few of us in the Java Desktop System group at Sun have just looked at binary-level symbol differences going from one version of the glib to a subsequent one. We observed that one global data item, and 16 function interfaces have been removed between the two versions summarized as follows: Report for: libglib-2.0.so.0.7.0 vs. libglib-2.0.so.0.400.1 Global Data changes: (from libglib-2.0.so.0.7.0 to libglib-2.0.so.0.400.1) Global Data removed (1): g__g_prgname_lock Functions changes: (from libglib-2.0.so.0.7.0 to libglib-2.0.so.0.400.1) Functions removed (16): _g_locale_charset combine g_bsearch_array_destroy g_bsearch_array_get_index g_bsearch_array_get_nth g_bsearch_array_insert g_bsearch_array_lookup g_bsearch_array_new g_bsearch_array_remove g_bsearch_array_remove_node g_convert_init g_main_thread_init g_mem_init g_messages_init g_mutex_init iconv_cache_bucket_new The question is whether these interfaces were intended to be part of glib's external programming interface, and whether the disappearance of these interfaces could therefore result in the breakage of existing compiled applications (or other layered libraries). We also examined atk, pango, gtk, glade and popt where we noted some additional interface removals. We can file bugs on those components as well if this kind of analysis is felt to be of importance. Finally, there is a question about whether certain symbols, which presently appear as globals, but which are actually intended for use only within the library itself can be scoped as local to that library, as part of the library's build (e.g. at the library's link-edit time).
For gtk, please take a look at what we've done in cvs HEAD recently. There are now explicit lists of exported symbols (gtk.symbols, gdk.symbols, etc) and we check in make distcheck that the list of exported symbols exactly matches these lists. In the process, we've made a number of accidentally exported symbols private. Looking at the glib symbols you found, g__g_prgname_lock this was accidentally exported, I can't imagine any application using it for anything. _g_locale_charset combine g_convert_init g_main_thread_init g_mem_init g_messages_init g_mutex_init iconv_cache_bucket_new same for these g_bsearch_array_destroy g_bsearch_array_get_index g_bsearch_array_get_nth g_bsearch_array_insert g_bsearch_array_lookup g_bsearch_array_new g_bsearch_array_remove g_bsearch_array_remove_node This change was intentional. Here is the relevant ChangeLog entry Tue Aug 19 03:55:29 2003 Tim Janik <timj@gtk.org> * glib/gbsearcharray.h: license change, no restrictions are made in the new license at all, the implmentation is simply provided "as is" to allow copy-pasting the code into any third-party app. naturally, the implementation is self-contained within the header file to allow this. default to non-shrinking behaviour, allow users to request shrinking via G_BSEARCH_ARRAY_AUTO_SHRINK. creation, deletion functions are now named g_bsearch_array_create() and g_bsearch_array_free(). fixed const in prototypes, removed cruft. (g_bsearch_array_insert): take only three arguments, do nothing if the node to insert is already there. (g_bsearch_array_replace): insert or replace if the node is already there. (g_bsearch_array_remove): remove nodes by index, the index of a node can be found via g_bsearch_array_get_index(). removed other g_bsearch_array_remove*() variants. (g_bsearch_array_lookup): minor optimizations. (g_bsearch_array_lookup_sibling): return nodes on mismatches. * glib/gbsearcharray.c: removed. This does in fact change the ABI.
But g_bsearcharray was never intended as public API - gbsearcharray.h is not included in glib.h, the header is not even installed. It is only used internally in gobject. If you want to file bugs for the symbols in the other libraries, go ahead, but I think we were pretty careful in managing the ABI.
Cool, thanks for taking a look. Looks like all the symbols were local anyway, and it was just an oversight not to scope them locally in the first place. We'll have to take a look at what you've done in CVS for symbol scoping, and see if we can't backport that to the libs we ship for JDS, but it's good to know that it'll just be there in the future. We'll go ahead and file bugs for the other libs, just to make sure that nothing slipped through. I doubt anything did, but it can't hurt to make sure. Thanks so much, Danek
Matthias, Thanks for your quick response and commentary. I know that you're also paying careful attention to the compatibility thing, which is partly why I thought this was worth your attention. Your info is very helpful: understanding the expected context of use of the interfaces in question is the key thing, and knowing how likely it is that someone may have got at interfaces not intended for public use (accidentally or otherwise) is also very helpful (i.e. your comments about the effective inaccessibility of the gbsearcharray.h header file). Something we've seen round here in the past about accessible globals in libraries, is that it's not always immediately obvious to folks who use a library (but who are not as close to its development), what's in vs. out of bounds (i.e. what's ABI and what's not). Indeed it's been amazing in some cases what we've seen some apps get at in our stuff in earlier days. Excellent news about your present symbol/interface management technology! We must get up to speed on that. -db