GNOME Bugzilla – Bug 769391
g_module_open returns the wrong error when loading libtool convenience libraries
Last modified: 2018-05-24 19:00:48 UTC
Created attachment 332488 [details] libtool convenience library wrapper exhibiting the problem g_module_open() mishandles libtool wrappers "*.la" files when they wrap internal project libraries. Libtool's documentation refers to such libraries as "Convenience Libraries" [1]. When pointed to such wrappers, g_module_open() will fail, as expected. However, the error returned by g_module_error() is misleading. For instance, when pointed to "../plugins/ctf/fs/libbabeltrace-plugin-ctf-fs.la", a convenience library, g_module_error() will return: "../plugins/ctf/fs/.libs/: cannot read file data: Is a directory" The problem was originaly encountered with glib 2.48.1 on Arch Linux, but was also reproduced using glib 2.32.4 on Ubuntu 12.04. Looking at the code, g_module_open() calls into parse_libtool_archive() to determine the path of the actual shared object to load. However, as you can see in the attached file, dlname is empty, a condition which is not checked for. This will cause parse_libtool_archive() to return a path to a directory which is ultimately passed to dlopen() and fails with the "Is a directory" error. My idea for a fix would be to check for this situation, set the current g_module error to "Could not load /path/to/thefile.la as it is a convenience library" using g_module_set_error and return NULL in parse_libtool_archive() Should I submit a patch? [1] https://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html
not sure it is worth a lot of effort to try and fail better here. Did you meet this situation in real life ?
I did. I have an application that searches for plug-ins on launch (in some pre-configured directory). That directory is traversed recursively to allow plug-ins to be kept in separate subfolders. In order to allow running the application from the source tree (mostly for devs), the application's libtool wrapper points it to the source directory's plug-in folder. That directory contains the actual plug-in shared objects, but also the various convenience libraries that they may depend on. Ultimately, this bug is not a show stopper, but it results in a noisy and confusing output as some "plug-ins" fail to load and the error is confusing both in that it mentions the module being a directory, but it is also printing a path that doesn't include the actual file being loaded. I think it is worth fixing as the fix I proposed is limited in scope and provides a clearer error message (or, hopefully, one that is google-able). I'm willing to provide a patch if it can help; I just want to confirm the approach beforehand. Thoughts?
-- 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/1185.