GNOME Bugzilla – Bug 780177
With --no-libtool, dumper is not linked to built library
Last modified: 2017-05-04 20:37:59 UTC
A bit of a difficult case to track down. I ran into it while trying to generate a .gir with Meson 0.37.1 and 0.39.1, which of course does not use libtool. But it's possible to reproduce it without Meson. testbug.c: #include <glib/gstdio.h> #include "testbug.h" void bug_hello(const char *greeting) { g_print("Hello, %s\n", greeting); } testbug.h: #pragma once void bug_hello(const char *greeting); $ gcc -c -fpic testbug.c `pkg-config --cflags --libs glib-2.0` $ gcc -shared -o libtestbug.so testbug.o $ g-ir-scanner testbug.[ch] --no-libtool --namespace=Bug --nsversion=0 --output Bug-0.gir --pkg=glib-2.0 --symbol-prefix=bug_ --identifier-prefix=Bug --library testbug ERROR: can't resolve libraries to shared libraries: testbug The error is being raised here [1]. What's happening is that the dumper binary is not linked to the built shared library, so it can't be matched in the dumper's ldd output. It's not getting linked because it passes its args array in here [2] to get_internal_link_flags(), expecting for it to be modified, but in the non-libtool case, get_internal_link_flags() doesn't add -ltestbug to the passed-in args array - only modifies the compiler instance [3], which does not show up in the dumper's link command line. [1] https://git.gnome.org/browse/gobject-introspection/tree/giscanner/shlibs.py#n129 [2] https://git.gnome.org/browse/gobject-introspection/tree/giscanner/dumper.py#n259 [3] https://git.gnome.org/browse/gobject-introspection/tree/giscanner/ccompiler.py#n140
Created attachment 348143 [details] [review] compiler: Modify args in get_internal_link_flags() In dumper.py, an args array is passed into this function and it expects to get all the necessary -l arguments added to it, in order to link the dumper binary to all the libraries it needs to be linked to. Without this, the dumper binary is not correctly linked in the non-libtool case.
I honestly cannot reproduce with Meson 0,37, 0.38, and 0.39. Your g-ir-scanner invocation is missing `-L/path/to/the/library` to let the linker know where libtestbug.so is, which is what Meson uses; the dumper utility is not built in the current directory, but in a temporary sub-directory; that's why it doesn't find the library you just built. Additionally, after bug 774625, the 'no-libtool' case of dependent libraries have been solved by adding the `--extra-library` command line argument.
I really can't get this to work at all, even with Meson 0.39.1. As an example, here's the full invocation of g-ir-scanner from my build of [1], with my own spacing added for readability and compiler options offset from g-ir-scanner options: /usr/bin/g-ir-scanner ../webhelper/lib/wh2private.c ../webhelper/lib/wh2private.h -pthread -I/usr/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include --no-libtool --namespace=WebHelper2Private --nsversion=1.0 --warn-all --output WebHelper2Private-1.0.gir --pkg=webkit2gtk-4.0 -I/home/philip/checkout/webhelper/ -I/home/philip/checkout/webhelper/_build/ --include=WebKit2-4.0 --symbol-prefix=wh2_ --identifier-prefix=Wh2 -I/usr/include/libxml2 -I/usr/include/webkitgtk-4.0 -I/usr/include/gtk-3.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/cairo -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -pthread -I/usr/include/atk-1.0 -I/usr/include/glib-2.0 -I/usr/include/libsoup-2.4 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi-2.0 -I/usr/include/pango-1.0 -I/usr/include/dbus-1.0 -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/harfbuzz -I/usr/include/freetype2 -L/home/philip/checkout/webhelper/_build/ -lwebkit2gtk-4.0 -lgtk-3 -lcairo -lgobject-2.0 -ljavascriptcoregtk-4.0 -lcairo-gobject -latk-1.0 -lpangocairo-1.0 -lglib-2.0 -lgdk-3 -lpango-1.0 -lgio-2.0 -lsoup-2.4 -lgdk_pixbuf-2.0 --library webhelper2private As you can see, the -L/path/to/the/library is there, and /home/philip/checkout/webhelper/_build/libwebhelper2private.so is present. I think my analysis that the dumper binary isn't being linked to libwebhelper2private.so is correct, but the question is why you aren't hitting the same thing... Maybe I am actually using Meson incorrectly in [1]? [1] https://github.com/endlessm/webhelper
Review of attachment 348143 [details] [review]: The dependencies should be handled by the `--extra-library` argument, but I think the issue with the built library not being linked is real. In some cases, under jhbuild, g-ir-scanner will attempt to link the dumper tool to the installed library, which will result in hard to track issues all over the place.
This is a dupe of bug 781525 — and should have been fixed by the patches attached to that bug. *** This bug has been marked as a duplicate of bug 781525 ***