GNOME Bugzilla – Bug 413870
Missing link flags prevents build with -z defs ld flags
Last modified: 2019-03-23 20:39:33 UTC
Hi, When jhbuilding esound with: os.environ['LDFLAGS'] = '-Wl,-z,defs' I get: Making all in changecase make[3]: entrant dans le répertoire « /home/lool/jhbuild-gnome-2.18/build/gedit/plugins/changecase » /bin/sh ../../libtool --tag=CC --mode=link gcc -Os -module -avoid-version -Wl,-O1 -Wl,-z,defs -o libchangecase.la -rpath /home/lool/jhbuild-gnome-2.18/prefix/lib/gedit-2/plugins gedit-changecase-plugin.lo gcc -shared .libs/gedit-changecase-plugin.o -Wl,-O1 -Wl,-z -Wl,defs -Wl,-soname -Wl,libchangecase.so -o .libs/libchangecase.so .libs/gedit-changecase-plugin.o: In function `gedit_changecase_plugin_init': gedit-changecase-plugin.c:(.text+0x45): undefined reference to `gedit_debug_message' .libs/gedit-changecase-plugin.o: In function `register_gedit_plugin': gedit-changecase-plugin.c:(.text+0x7e): undefined reference to `gedit_debug_message' gedit-changecase-plugin.c:(.text+0xa8): undefined reference to `gedit_plugin_get_type' gedit-changecase-plugin.c:(.text+0xc6): undefined reference to `g_type_module_register_type' .libs/gedit-changecase-plugin.o: In function `gedit_changecase_plugin_class_intern_init': ... This is due to missing link flags in this plugins; I'll attach a patch adding GEDIT_LIBS like the other plugins do and libgedit.la as this is required for gedit_debug stuff. Bye,
Created attachment 83729 [details] [review] Link changecase plugin with GEDIT_LIBS and libgedit.la
Created attachment 83731 [details] [review] Fix link flags of plugins The build subsequently fails with: make[3]: entrant dans le répertoire « /home/lool/jhbuild-gnome-2.18/build/gedit/plugins/docinfo » /bin/sh ../../libtool --tag=CC --mode=link gcc -Os -module -avoid-version -Wl,-O1 -Wl,-z,defs -o libdocinfo.la -rpath /home/lool/jhbuild-gnome-2.18/prefix/lib/gedit-2/plugins gedit-docinfo-plugin.lo -Wl,--export-dynamic -pthread -L/home/lool/jhbuild-gnome-2.18/prefix/lib -lgtksourceview-1.0 -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnome-keyring -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lglade-2.0 -lgnomeprintui-2-2 -lgnomeprint-2-2 -lz -lgnomecanvas-2 -lxml2 -lart_lgpl_2 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgnomevfs-2 -lgconf-2 -lgmodule-2.0 -ldl -lORBit-2 -lgthread-2.0 -lrt -lgobject-2.0 -lglib-2.0 gcc -shared .libs/gedit-docinfo-plugin.o -Wl,--rpath -Wl,/home/lool/jhbuild-gnome-2.18/prefix/lib -Wl,--rpath -Wl,/home/lool/jhbuild-gnome-2.18/prefix/lib -L/home/lool/jhbuild-gnome-2.18/prefix/lib /home/lool/jhbuild-gnome-2.18/prefix/lib/libgtksourceview-1.0.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libgnomeui-2.so -lSM -lICE /home/lool/jhbuild-gnome-2.18/prefix/lib/libbonoboui-2.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libgnome-keyring.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libgnome-2.so /usr/lib/libpopt.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libbonobo-2.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libbonobo-activation.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libglade-2.0.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libgnomeprintui-2-2.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libgnomeprint-2-2.so -lz /home/lool/jhbuild-gnome-2.18/prefix/lib/libgnomecanvas-2.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libxml2.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libart_lgpl_2.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libgtk-x11-2.0.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libgdk-x11-2.0.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libatk-1.0.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libgdk_pixbuf-2.0.so -lm /home/lool/jhbuild-gnome-2.18/prefix/lib/libpangocairo-1.0.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libpango-1.0.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libcairo.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libgnomevfs-2.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libgconf-2.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libgmodule-2.0.so -ldl /home/lool/jhbuild-gnome-2.18/prefix/lib/libORBit-2.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libgthread-2.0.so -lrt /home/lool/jhbuild-gnome-2.18/prefix/lib/libgobject-2.0.so /home/lool/jhbuild-gnome-2.18/prefix/lib/libglib-2.0.so -Wl,-O1 -Wl,-z -Wl,defs -Wl,--export-dynamic -pthread -Wl,-soname -Wl,libdocinfo.so -o .libs/libdocinfo.so .libs/gedit-docinfo-plugin.o: In function `gedit_docinfo_plugin_init': gedit-docinfo-plugin.c:(.text+0x45): undefined reference to `gedit_debug_message' .libs/gedit-docinfo-plugin.o: In function `register_gedit_plugin': gedit-docinfo-plugin.c:(.text+0x7e): undefined reference to `gedit_debug_message' gedit-docinfo-plugin.c:(.text+0xa8): undefined reference to `gedit_plugin_get_type' .libs/gedit-docinfo-plugin.o: In function `gedit_docinfo_plugin_class_intern_init': gedit-docinfo-plugin.c:(.text+0x107): undefined reference to `gedit_plugin_get_type' .libs/gedit-docinfo-plugin.o: In function `gedit_docinfo_plugin_finalize': gedit-docinfo-plugin.c:(.text+0x172): undefined reference to `gedit_debug_message' libgedit.la seems to be missing from the docinfo, filebrowser, indent, sample, sort, taglist, time, spell, and modelines plugins as well. I'm attaching a new patch which covers all plugins.
GEDIT_LIBS missing from changecase is definately an oversight and should be fixed, but I don't like linking plugins to libgedit.la: libgedit is just a internal library and is not installed so plugins should not need to link against it. Plugins are meant to be dlopened by gedit itself and the symbols are meant to be resolved at runtime... is there something I am missing?
Hmmm, it's a bad idea to link against libgedit.la in this case indeed as it will increase the size of the plugins needlessly. I fear the plugins wont built under WIN32 without it though. I suppose one solution might be to make the gedit binary both a shared lib and an executable, just like the libc, and link against it. It seems Rhythmbox went on to ship a shared lib, so this is another route to follow. I'll give some thought to the issue and perhaps ping some folks to see what they think of it -- unless you want to follow one of the two solutions above? Could you checkin the GEDIT_LIBS part in the meantime? Thanks!
I exchanged some mails with Tor Lillqvist, and he suggested using g_module_symbol() here as well: """ > Problem type c) concerns applications with modules such as gedit; in a > similar way to Python bindings, some symbols such as gedit_debug_msg() > will be resolved when the gedit binary loads the relevant *.so module, Run-time explicit lookup of symbols would be the cleanest solution here, too, I think. """ I asked for clarifications since I didn't know one can use g_module_symbol in this way: """ > I've grepped for uses of > g_module_symbol(), and saw that for example Gtk uses it to find symbols > in plugins, for example to find im_module_init() in IM modules, > theme_init() in engines etc., but this does not seem to be used the > other way around, that is for a module to locate symbols in the binary > loading it. It isn't common, I guess, but it should work this way too. Calling g_module_open(NULL, flags) "opens" the program's executable itself. > How did you mean g_module_symbol() should be used here? The dynamically loaded module looks up symbols from the main program by calling g_module_open(NULL, flags) to get a module handle for the main executable, and then looks up symbols from that with g_module_symbol(). For this to work on Win32 (and maybe other systems, too), the symbols to be "exported" from the main program need to be marked with the G_MODULE_EXPORT attribute. See module-test.c in glib/test. """ Do you think it would be an option to do this for gedit? (Add g_module_symbol calls at the top of each plugin.) I imagine that a shared library would be easier to maintain though; which solution would you prefer?
I'd say a shared lib would probably be easier, dunno have to think a bit about that
I'm closing this since I'm assuming this issue is fixed now (we have plugins on win32...). Feel free to reopen if the problem still exists.