After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 780177 - With --no-libtool, dumper is not linked to built library
With --no-libtool, dumper is not linked to built library
Status: RESOLVED DUPLICATE of bug 781525
Product: gobject-introspection
Classification: Platform
Component: g-ir-scanner
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Reported: 2017-03-17 02:41 UTC by Philip Chimento
Modified: 2017-05-04 20:37 UTC
See Also:
GNOME target: ---
GNOME version: ---

compiler: Modify args in get_internal_link_flags() (1.10 KB, patch)
2017-03-17 02:44 UTC, Philip Chimento
reviewed Details | Review

Description Philip Chimento 2017-03-17 02:41:36 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.


    #include <glib/gstdio.h>
    #include "testbug.h"
    void bug_hello(const char *greeting) {
        g_print("Hello, %s\n", greeting);


    #pragma once
    void bug_hello(const char *greeting);

$ gcc -c -fpic testbug.c `pkg-config --cflags --libs glib-2.0`
$ gcc -shared -o 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.

Comment 1 Philip Chimento 2017-03-17 02:44:45 UTC
Created attachment 348143 [details] [review]
compiler: Modify args in get_internal_link_flags()

In, 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.
Comment 2 Emmanuele Bassi (:ebassi) 2017-03-19 00:53:41 UTC
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 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.
Comment 3 Philip Chimento 2017-04-12 20:41:37 UTC
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
  --output WebHelper2Private-1.0.gir
  --library webhelper2private

As you can see, the -L/path/to/the/library is there, and /home/philip/checkout/webhelper/_build/ is present. I think my analysis that the dumper binary isn't being linked to is correct, but the question is why you aren't hitting the same thing... Maybe I am actually using Meson incorrectly in [1]?

Comment 4 Emmanuele Bassi (:ebassi) 2017-04-20 09:58:55 UTC
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.
Comment 5 Emmanuele Bassi (:ebassi) 2017-05-04 20:37:59 UTC
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 ***