GNOME Bugzilla – Bug 134813
g_slist_remove_all export from gobject DLL
Last modified: 2011-02-18 16:07:18 UTC
It appears that, at least in my linux-x-mingw32 binaries, the gobject DLL created from glib 2.2.3 exported g_slist_remove_all (see gobject.def). Obviously this was a bug which has now been corrected in 2.3.2. The problem is that any programs which were built against glib 2.2.3 look for that symbol in the gobject DLL and not in the glib DLL. This causes them to fail to run if glib (and the gobject DLL) is upgraded.
I think g_slist_remove_all should be added back to gobject.def for bug compatibility. 2.4.0 probably won't be usable as such on Windows anyway, so setting milestone to 2.4.1.
What makes you believe that glib 2.4.0 won't be useable under Windows? I'm using glib 2.3.2 quite happily in the application I'm currently writing (gtk+ 2.3.2 won't even build, but that's another matter).
> What makes you believe that glib 2.4.0 won't be useable under Windows? Oh, it was just a wild guess, based on my impression that some API has been added recently, but the corresponding entries haven't been added to the .def files for instance. And the g_child_watch stuff hasn't been implemented yet for Windows, and the current source in fact contains for instance calls waitpid() and uses SIGCHLD without any ifdefs. (I have been extremely busy at work lately, and really not had any time for glib etc hacking at home for many weeks.)
To the original report: IMO providing bug compatibility is absolutely unnecessary, at least if the function was only exported in the unstable 2.3.x series. So I'm suggesting to close as WONTFIX
Sadly it's not that easy. The problem is that version 2.2.3 (and probably the rest of the 2.2.x stable series) exported the symbol in error. This only came to light with version 2.3.2, but if nothing is done the 2.4.x series will be incompatible with the 2.2.x series. I'm hoping to persuade Tor that this should be fixed for 2.4.0 (or not at all) otherwise 2.4.0 and 2.4.1 may end up being incompatible with each other (not sure whether the same problem will manifest itself in reverse). To this end I have submitted patches to address the two issues which Tor states would have caused 2.4.0 to be unusable under Windows. I realize this still leaves quite a bit of work to do and therefore may not be enough to achieve my goal.
> providing bug compatibility is absolutely unnecessary, > at least if the function was only exported in the > unstable 2.3.x series. No, it has been exported in the stable series for a long time. (BTW, are we sure that programs that use g_slist_remove_all(), and import it from the gobject DLL, actually work? I don't know how such a "redirected import" is implemented in a DLL. Maybe it works fine. None of the test programs in glib use g_slist_remove_all().)
> (BTW, are we sure that programs that use g_slist_remove_all(), and > import it from the gobject DLL, actually work? I don't know how such > a "redirected import" is implemented in a DLL. Maybe it works fine. > None of the test programs in glib use g_slist_remove_all().) I can confirm that this does work. I used the attached patch to check.
Created attachment 24982 [details] [review] Test case
Fixed: 2004-03-01 Tor Lillqvist <tml@iki.fi> * gobject.def: Add g_slist_remove_all back for ABI compatibility. That entry point actually is in the glib DLL, but it was at some time many years ago by mistake added to gobject.def. Thus there presumably are executables out there that expect it to be exported from the gobject DLL. We don't want to break those. (#134813, J. Ali Harlow)