GNOME Bugzilla – Bug 449562
glade3 broken on Cygwin
Last modified: 2007-06-26 20:25:28 UTC
All versions of glade3 seem unable to load symbols from its plugins, e.g.: ** (glade-3:3048): WARNING **: We could not find the symbol "bonobo_dock_item_get_type" ** (glade-3:3048): WARNING **: Could not get the type from "BonoboDockItem" ** (glade-3:3048): WARNING **: Failed to load the GType for 'BonoboDockItem' Launching glade3 returns numerous such warnings, and when the window appears, no widgets are available. I have confirmed that glade3 is loading the right plugin filename. Could someone provide some direction to help figure this out?
I don't know about Cygwin, but I build glade3 often using mingw/msys, and everything works. It seems in your case that the GNOME widget plugin has been enabled because configure found libgnomeui/libbonobui. It is possible that dependencies for libbonoboui and libgnomeui are not installed. Please check this. Some esoteric dependencies include gnome-vfs and openssl. Someone else I had a similar problem and it turned out that libgnomeui depended on openssl, and this was not installed. Try disabling the GNOME plugin by passing the `--disable-gnome' configure option. In fact I would recommend this since GNOME is not really supported at all on Windows.
The Gtk* symbols are not loaded either; I chose BonoboDockItem as the example because it was last and easiest to copy from terminal. Perhaps you are not familiar with Cygwin Ports. All GNOME libraries and their dependencies are properly installed, and numerous programs that depend on them or their C++/C#/Perl/Python/Ruby bindings and work just fine, including most of the entire official desktop, anjuta, glom, gnumeric, gthumb, liferea, mail-notification, mergeant, totem, and more. So therefore I assure you that this is not nearly so simple. I have looked through relevant sections of the code, and have not found anything obvious yet. I would therefore like to ask the developers if they can help me figure out what would be causing this.
Ok, I see. Thanks. So why does glade3 work on mingw/msys (or UNIX) and not on Cygwin? Is there some difference between the two platforms, in their handling of dynamic modules? That is a clue which could help us. I would also need more information. Can I see the config.log file? Here is the offending function (in case you have not seen it yet): glade_util_get_type_from_name()
OK, that gets me somewhere. This concerns me: if (!allsymbols) allsymbols = g_module_open (NULL, 0); AFAIK this means that the caller should g_module_open() itself, and from there, the symbols will be found. Where is this ultimately being called, and how does that help us find symbols in libgtk/libbonoboui/libgnomeui?
Created attachment 90416 [details] g_module_self test OK, I'll partially answer my own question. From POSIX.1 [1]: "Note that some implementations permit the construction of dependencies between such objects that are embedded within files. In such cases, a dlopen() operation shall load such dependencies in addition to the object referenced by file." [1] http://www.opengroup.org/onlinepubs/009695399/functions/dlopen.html I guess that answers the question for linux, as gmodule-dl.c _g_module_self() uses dlopen(). For gmodule-win32.c, this appears to be accomplished with a serious hack. I'm not familiar enough with the other platforms to understand if and how they do the same. I think I'm making progress, but I need to understand these other platforms. I'm attaching a simple test binary. What are your testing platform and results?
OK, I will test it soon, I am just busy with some other stuff. Also, I noticed that we do not pass the `--export-dynamic' linker flag for our executable. We do not add the G_MODULE_EXPORT attribs on plugins either. Anyway, just food for thought. man ld: --export-dynamic: When creating a dynamically linked executable, add all symbols to the dynamic symbol table. The dynamic symbol table is the set of symbols which are visible from dynamic objects at run time. If you do not use this option, the dynamic symbol table will normally contain only those symbols which are referenced by some dynamic object mentioned in the link. If you use "dlopen" to load a dynamic object which needs to refer back to the symbols defined by the program, rather than some other dynamic object, then you will probably need to use this option when linking the program itself Will perform the test soonish.
I don't know if either is actually necessary in this case, since AFAICS your not trying to load the symbols in glade-3$(EXEEXT), rather those of the loaded dependencies. Other programs do have this problem, but I don't see it here. For the record, the test results on Cygwin 1.5.24-2 with GLib 2.12.12-1 are: I can g_module_open() myself... and I can g_module_symbol() myself with G_MODULE_EXPORT... but I can't g_module_symbol() my deps. (I think now this is actually a gmodule and/or cygwin problem, but I'll see those results first.)
Vincent, I noticed that when we stopped using the LIBGLADEUI_API prefix in header files and you added the autogenerated gladeui.defs file, we didnt add this to the plugins. If the defs file is the only way to expose the public symbols in shared libs on win32 then we should add that mumbojumbo to the plugin makefiles.
Created attachment 90431 [details] [review] glade3 Cygwin build patch OK, I've fixed the symbol loading in gmodule, and glade3 now works. For my own knowledge, I still would to see the test results when you have a chance. I'm now attaching a patch to fix a minor build issue on Cygwin, completely unrelated to the issue raised before. * configure.ac: Differentiate between native MinGW and Cygwin. * bindings/python/Makefile.am: * gladeui/Makefile.am: * plugins/gnome/Makefile.am: * plugins/gtk+/Makefile.am: -no-undefined is required for all Win32 platforms. * src/Makefile.am: -mwindows is only required on Cygwin.
Here are the test results: gcc -o main gmodule-self-test.c `pkg-config --cflags --libs gtk+-2.0 gmodule-2.0` ./main I can g_module_open() myself... and I can always g_module_symbol() myself... and I can g_module_symbol() my deps! Note that the test incorrectly passed `gpointer sym' to g_module_symbol. I changed it to `gpointer &sym' as per the docs. You may want to try the test again because of this.
Oh, and I am running Linux
OK, about the patch... As I see it, you added a second configure check for "native windows" simply so that the "-mwindows" linker flag could be added for the final executable. The problem is that this flag hides the console, effectively hiding any errors and warnings. I really want to have this console visible during development, as it has led to me fixing many bugs as a result. Simply passing the flag as below will do for production builds: LDFLAGS="-mwindows" ./configure
Re comment 10: Thanks for the correction (I never claimed to be an expert programmer), but this doesn't change anything, as sym isn't actually used. With my patch to gmodule though, I do get: I can g_module_open() myself... and I can g_module_symbol() myself with G_MODULE_EXPORT... and I can g_module_symbol() my deps! Which is what I expect, and should be the results on MinGW as well. Re comment 12: Perhaps you want the -mwindows flag also dependent on 'if !MAINTAINER_MODE' (and adding AM_MAINTAINER_MODE to configure.ac if necessary)?
> Re comment 12: > Perhaps you want the -mwindows flag also dependent on 'if !MAINTAINER_MODE' > (and adding AM_MAINTAINER_MODE to configure.ac if necessary)? > Ok, that sounds reasonable. If you can cook up a patch please :)
Created attachment 90492 [details] [review] glade3 Cygwin build patch * configure.ac: Differentiate between native MinGW and Cygwin. * bindings/python/Makefile.am: * gladeui/Makefile.am: * plugins/gnome/Makefile.am: * plugins/gtk+/Makefile.am: -no-undefined is required for all Win32 platforms. * src/Makefile.am: -mwindows is only required on MinGW. Also, don't pass -mwindows with --enable-maintainer-mode for developers.
Ok, I have been thinking about how to cleanly support "-mwindows" without interfering with the development process. I decided that the maintainer mode approach isn't the best solution. I see that GIMP always compiles with "-mwindows". If the codebase is deemed "unstable" (decided by interpreting odd/even version numbers), then GIMP will open up it's own console entirely controlled by itself (through fancy win32 API calls). I think we may able to go one better and just create a console using pure GTK+ (GtkWindow and GtkTextView). Will create a patch to investigate.
I have gone off the special console approach. A bit of an overkill for our needs. Instead, I have just defined the macro/conditional GLADE_UNSTABLE, with a value of true if we are in an unstable development cycle. If GLADE_UNSTABLE is false then we use "-mwindows". I think this makes both developers and users happy. Cygwin Ports maintainer, I am going to update your patch to implement that.
Created attachment 90628 [details] [review] Patch for trunk
Created attachment 90629 [details] [review] Patch for gnome-2-18 branch
Created attachment 90645 [details] [review] Patch for trunk (revised) The patch for trunk needs is not quite right; here's a new patch.
ok, thanks. It seems we are not making another 3.2.x release, so I have only applied the trunk patch. Marking as RESOLVED/FIXED.