GNOME Bugzilla – Bug 640446
Include the full library path in shared-library, rather than the soname only
Last modified: 2018-02-08 12:03:12 UTC
Having only the soname means that the version loaded is from the path in ld.so and binary rpath, which may be different from the path the actual library is installed into. For example with python, unless you rebuild it to include your custom libdir, you have no control on library search paths. In particular: 1) If the library uses unversioned sonames (like Gtk and GLib), an incompatible version may be loaded, causing runtime failures. 2) If the libdir is not added to ld.so/rpath, module importing will just fail. Real world use case: GNOME Shell uses libgnome-bluetooth-applet.so, which is installed into $(libdir)/gnome-bluetooth/. It cannot modify the RPATH for dlopened modules (it is in mutter, not libgnome-shell.so), so it adds a fake DT_NEEDED to get it always loaded - but this fails with --as-needed (which is the default in some distributions), because it does not use any symbol from libgnome-bluetooth-applet in compiled code. Bug 639324.
Created attachment 179193 [details] [review] Include full library path in GIR In the shared-library attribute, include the full library path, obtained from the libdir attribute of the libtool archive. This way modules can be dynamically loaded and imported even if they reference shared objects from paths not included in the binary DT_RPATH.
If gnome-bluetooth intends to install a generally useable library (instead of a dlopened module), then it better be available in the regular ld.so search path.
(In reply to comment #2) > If gnome-bluetooth intends to install a generally useable library (instead of a > dlopened module), then it better be available in the regular ld.so search path. It is not a "generally useable library", in the sense that it should be used only by gnome-shell (and gnome-bluetooth itself), but it needs to be dlopened by libgirepository, which has no special knowledge of it.
I don't like this; it defeats use of LD_LIBRARY_PATH among other things. How about we explicitly dlopen libgnome-bluetooth from the gnome-shell plugin? Get its full path during configure, add that to config.h via AC_DEFINE, then dlopen it early.
(In reply to comment #4) > How about we explicitly dlopen libgnome-bluetooth from the gnome-shell plugin? > Get its full path during configure, add that to config.h via AC_DEFINE, then > dlopen it early. we already get its path, because we also have to do: g_irepository_prepend_search_path (BLUETOOTH_DIR); so that libgirepository can find the (private) typelib file. Maybe that function (or something else) could also modify the library search path?
(In reply to comment #5) > (In reply to comment #4) > > How about we explicitly dlopen libgnome-bluetooth from the gnome-shell plugin? > > Get its full path during configure, add that to config.h via AC_DEFINE, then > > dlopen it early. > > we already get its path, because we also have to do: > > g_irepository_prepend_search_path (BLUETOOTH_DIR); > > so that libgirepository can find the (private) typelib file. Maybe that > function (or something else) could also modify the library search path? In that case we would need a g_module_add_run_path inside GLib, and modify g_module_open to try each path in succession. It would mean reimplementing partially library name resolution. There is no other way to set the path with libc / libdl. If that is done, though, we can consider using separate "libdir" and "shared-library" attributes in .gir files, so that LD_LIBRARY_PATH keeps working as expected. (Is it really supported in general to replace libraries at run time?)
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
-- 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/gobject-introspection/issues/43.