GNOME Bugzilla – Bug 591669
introspection typelib should reference library SONAME
Last modified: 2015-02-07 16:52:20 UTC
This is on Mandriva Cooker with clutter 1.0.0. When I try to run gnome-shell, I get an error like this: Failed to load shared library 'clutter-glx-1.0' referenced by the typelib: libclutter-glx-1.0.so: Cann on open shared library: No such file or directory The symlink libclutter-glx-1.0.so is not there as it is packaged in the -devel package. I think the typelib should contain a reference to libclutter-glx-1.0.so.0 instead. The clutter devs told me that it was generated like that by gobject-introspection: http://bugzilla.openedhand.com/show_bug.cgi?id=1762 I think the library SONAME should be referenced in the typelib. Users usually don't have the .so symlink on their systems.
A quick note here is that it does *usually* reference the soname, e.g.: $ strings /home/otaylor/gnome-shell/install/lib/girepository-1.0/Clutter-1.0.typelib | grep glx libclutter-glx-1.0.so.0 so there is work to be done to figure out under what circumstances it references the .so and why. (Help appreciated if you can reproduce this - I had one report of this happening on Fedora, but it wasn't immediately reproduceable for me. Report was on x86_64)
$ strings /usr/lib/girepository-1.0/Clutter-1.0.typelib |fgrep glx clutter-glx-1.0 This is with plain gobject-introspection 0.6.3 on i586.
So, it's different for you. But why? (It may be apparent looking at the g-ir-scanner code - I haven't looked yet.)
Can you try: $ python >>> import ctypes.util >>> ctypes.util.find_library('clutter-glx-1.0') >>> ctypes.util._get_soname('/usr/lib/libclutter-glx-1.0.so') I get 'libclutter-glx-1.0.so.0' for both.
When I build it on my machine with clutter-devel already installed, the reference is correct, but in the build bot, where clutter is not installed, I get the mentioned wrong reference.
to #4: I get the same, if libclutter is installed in the system. So the g-ir-scanner doesn't use the just built libclutter but the one installed in the system.
Thanks, that's useful.
The .gir file already contains the wrong reference. I workaround is to add -L .libs to the call of /usr/bin/g-ir-scanner
Working on a fix now.
Created attachment 140703 [details] [review] Resolve library names to shared libraries ourselves binary to find the SONAME. I'm pretty happy with this in the context of the combination of an "ELF-like" platform and libtool. * libtool, not-ELF-like Requires some replacement for ldd to be added to the code here. On OS X, you could use otool instead (with different output parsing code). On windows, less clear. There much less of a tradition of mapping -l<foo> map predictably to to DLL names, so even if you can get the DLL's that the binary is linked to (certainly should be possible), it's not completely clear how to find which one of them is -l<foo>. As far as I recall, the ideal thing for windows would be to search the linker's search path for the .lib file, and use *that* to figure out the DLL name. * No libtool The same considerations apply as to libtool will work if the caller does LD_LIBRARY_PATH=/path/to/solib when calling giscanner. (or for non-ELF-platforms, the equivalent.) And for the introspection binary to run, they have to set that anyways. So, basically as long as we're willing to leave non-ELF as an exercise to the reader, this should work out OK, I hope. The maain alternative I see is parsing libtool files and extracting the 'dlname' from there. Then you'd invoke the scanner as: --library=libfoo-1.2.la special case libraries ending in .la and use completely different code-paths for that compared to other libraries. That would be likely be simpler than this (since we already have that .la extraction code in utils.py), and more portable, so maybe this patch should be ignored. I didn't fully work out that approach until writing this comment. Would like to get feedback before I embark on rewriting that way, however.
The whole intersection between: * libtool vs not * ELF versus OS X versus Win32 * gir-repository versus build-inside-library (clutter) versus introspect-binary (mutter) terrifies me frankly =) I think just working in the libtool+ELF for all 3 of the introspection targets is fine. The patch looks reasonable, if it fixes problems for people let's get it in. Might be worth adding your comment text here inside the code itself, or at least a reference to this bug.
Created attachment 140739 [details] [review] Support passing --library=lib<foo>.la In addition to the current --library=<foo>, support --library=lib<foo>.la. This makes it unambiguous that we are referencing an uninstalled library and allows accurate extraction of the shared library name for the uninstalled library. * tests/scanner/Makefile.am tests/offsets/Makefile.am: Use the new form of --library=. Also some LD_LIBRARY_PATH frobbing as needed. *-expected.gir *-expected.tgir: We now pick out the shared library accurately, so fix shared-library="" in our reference girs. (The comparison may need some pre-sanitization now to work on non-ELF)
The patch I just attached adds the ability to read the .la *in addition* to my previous approach. With luck this should get us working for libtool on non-ELF systems as well. Leaving only non-ELF non-libtool to be fixed. I don't think we want a further fallback to the ctypes.util method we used to use. ctypes.util is very much in the spirit of "try to find something, and hope it's the right thing". Which could easily lead to breakage a long way down the build line. (Looking at the ctypes code, I don't think it handles LD_LIBRARY_PATH at all - the primary method on Linux is to use ldconfig -p to list shared libraries, and that won't list shared libraries that are only in LD_LIBRARY_PATH. So, you might get the soname from the system install when there was something newer in LD_LIBRARY_PATH, for example.)
+def extract_libtool_shlib(la_file): Might make sense to move these all to shlibs.py? Otherwise this patch looks good.
(In reply to comment #14) > +def extract_libtool_shlib(la_file): > > Might make sense to move these all to shlibs.py? > > Otherwise this patch looks good. My reasoning was that libtoolimporter.py shouldn't reference shlibs.py - since shlibs.py is specifically about the library resolution process. And if extract_libtool() stays in utils.py then _extract_dlname_field needs to stay too. And then I figured it was better to keep the logic for converting the dlname field to the shlib name with the rest of the comments about differences between libtool versions, etc, rather than splitting it into shlibs.py.
Applied, thanks!
With the latest gobject-introspection from git, clutter does not build anymore: GEN Cogl-1.0.gir /home/goetz/rpm/BUILD/clutter-1.0.2/clutter/cogl/cogl-shader.h:110: syntax error, unexpected '*', expecting ')' or ',' /home/goetz/rpm/BUILD/clutter-1.0.2/clutter/cogl/cogl-texture.h:61: syntax error, unexpected identifier, expecting ')' or ',' /home/goetz/rpm/BUILD/clutter-1.0.2/clutter/cogl/cogl-texture.h:98: syntax error, unexpected identifier GEN Cogl-1.0.gir ERROR: can't resolve libraries to shared libraries: clutter-cogl Is this a problem of clutter's build system?
I have patched clutter like this: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/clutter/current/SOURCES/clutter-1.0.2-gobject-introspection-fix.patch?revision=417241&view=markup
This patch breaks the build on OSX and probably on MSWindows: *** Building gobject-introspection *** [1/1] make make all-recursive Making all in girepository make[2]: Nothing to be done for `all'. Making all in giscanner make all-am make[3]: Nothing to be done for `all-am'. Making all in tools GEN g-ir-scanner Making all in gir GISCAN GLib-2.0.gir ../libtool: line 8858: exec: ldd: not found ERROR: can't resolve libraries to shared libraries: glib-2.0 make[2]: *** [GLib-2.0.gir] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Here's the detailed output from make V=1: make[2]: Nothing to be done for `all'. Making all in gir env LPATH=.libs env PYTHONPATH=..:..:YTHONPATH UNINSTALLED_INTROSPECTION_SRCDIR=.. UNINSTALLED_INTROSPECTION_BUILDDIR=.. ../tools/g-ir-scanner -v --add-include-path=../gir --add-include-path=. -v --add-include-path=../gir --add-include-path=. --namespace=GLib --nsversion=2.0 --libtool="/bin/sh ../libtool" --library=glib-2.0 --pkg=glib-2.0 --noclosure --strip-prefix=g --c-include="glib.h" -I/usr/local/gtk-unstable/inst/include -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -I/usr/local/gtk-unstable/inst/include/glib-2.0 -I/usr/local/gtk-unstable/inst/lib/glib-2.0/include -DGETTEXT_PACKAGE=Dummy -DGLIB_COMPILATION -D__G_I18N_LIB_H__ /usr/local/gtk-unstable/inst/lib/glib-2.0/include/glibconfig.h /usr/local/gtk-unstable/inst/include/glib-2.0/glib/*.h ./glib-2.0.c --output GLib-2.0.gir ../libtool: line 8858: exec: ldd: not found ERROR: can't resolve libraries to shared libraries: glib-2.0
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]