GNOME Bugzilla – Bug 107626
g_module_symbol(NULL, ...) fails with loaded modules
Last modified: 2018-05-23 23:14:18 UTC
i am seeing this bug in evolution. what happens is, a bonobo shlib component uses libglade, and uses the symbol lookup parts of g_module. this fails, because the symbols aren't defined in the "self" module, but in a loaded module. eg, gfrob loads libfoo_comp.so using gmodule. libfoo_comp.so calls g_module_symbol (NULL, "foo_function"). this fails on OS X, but apparently works on linux. a simple workaround is to try looking up the symbol in the previoiusly loaded modules (see attached patch).
Created attachment 14786 [details] [review] try searching previously loaded modules
Wouldn't a solution more consistent with the dlopen() path be to remove NSLINKMODULE_OPTION_PRIVATE from gmodule-dyld.c:_g_module_open()? The dlopen() code always uses RTLD_GLOBAL.
I believe I tried that, and that broke plug-ins where they export a known symbol that the app looks up in them, ie. a g_frob_plugin_init() function.
I have a hard time giving a good answer here about what is right because: - The behavior differs significantly from operating system to operating system already - The presence of RTLD_GLOBAL in for dlopen() is basically a leftover of workarounds for bugs in GNU libc and libtool that were fixed years ago. (I'd love to be able to just get rid of it if we could) - The glade_xml_autoconnect() usage you mention is a bit weird, but I don't have a good alternative; something like: glade_xml_autoconnect_module (xml, g_module_current ()); would make sense, but portable implementation is close to impossible. GCC/GNU libc you can do it with __builtin_return_address() and dladdr()... So, that all being said, if you think this patch is the right thing to do, we should add it. But it seems to me that there should be a comment by the NSLINKMODULE_OPTION_PRIVATE usage that describes in particular what goes wrong there ...hopefully more specifically than "something broke" Does NSSymbolInModule not work on globally loaded modules? Can you not have two globally loaded modules with the same symbol? Or..? If you have Pango installed, you could check pretty easily by removing the PRIVATE flag, making install, then running pango-querymodules. And a comment here that references that and describes what we are doing. I think there is a definite need to leave a breadcrumb trail for the next person who touches this code.
> Can you not have two globally loaded modules with the > same symbol? Right. If you don't use NSLINKMODULE_OPTION_PRIVATE, then if any two modules define the same non-static symbol as each other or as the main program, then it the linker aborts immediately upon trying to open the module. So module-test will fail because of the three g_clash_func()s (and evolution would fail because of the camel_provider_init() in each camel module). Coincidentally, this bug just came up on a NetBSD list yesterday. It looks like NetBSD doesn't implement RTLD_GLOBAL to mean the same thing as it does on Linux. Dunno about the other BSDs.
If the use of RTLD_GLOBAL is a bug, then getting rid of it would be a Good Thing, because it would prevent the bug discussed in http://mail.gnu.org/archive/html/bug-glibc/2003-06/msg00141.html from ocurring.
We are still applying this patch downstream on Gentoo, but no idea about its status now with glib-2.32 (it still applies but I don't have a bsd system to check if it's really needed)
(In reply to comment #7) > We are still applying this patch downstream on Gentoo, but no idea about its > status now with glib-2.32 (it still applies but I don't have a bsd system to > check if it's really needed) Wow, blast from the past. So you're applying a patch for the MacOS X backend for Gentoo? Do you guys have like any idea what you're doing at all?
We are applying a different one due: https://bugs.gentoo.org/show_bug.cgi?id=184301 this is the patch: https://184301.bugs.gentoo.org/attachment.cgi?id=123959
(In reply to comment #9) > We are applying a different one due: > https://bugs.gentoo.org/show_bug.cgi?id=184301 > > this is the patch: > https://184301.bugs.gentoo.org/attachment.cgi?id=123959 Any notes about this patch?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/7.