g_module_open returns the wrong error when loading libtool convenience libraries
Submitted by Jérémie Galarneau
Link to original bug (#769391)
Description
Created attachment 332488 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
Attachment 332488, "libtool convenience library wrapper exhibiting the problem":
libbabeltrace-plugin-ctf-fs.la
Version: 2.48.x