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 791991 - Broken shared-library value in gir files on *BSD when builddir includes the name of the library
Broken shared-library value in gir files on *BSD when builddir includes the n...
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: g-ir-scanner
unspecified
Other FreeBSD
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-12-27 18:53 UTC by Ting-Wei Lan
Modified: 2018-01-20 12:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
giscanner: Fix shared library name finding on *BSD (1.24 KB, patch)
2017-12-27 18:59 UTC, Ting-Wei Lan
committed Details | Review

Description Ting-Wei Lan 2017-12-27 18:53:12 UTC
Sometimes the name of a project includes 'lib', such as libgepub, libgusb, libgxps. If we build them in a directory having the same name as the library, giscanner/shlibs.py can wrongly match the name of current working directory with _ldd_library_pattern when reading the output of ldd command.

For example, I put the source of libgepub in /home/lantw44/gnome/source/libgepub and build it in /home/lantw44/gnome/build/libgepub. Since the library is named 'libgepub' and the full path of working directory also includes the name 'libgepub', it will match the first line of ldd output, which is the full path to the executable built by g-ir-scanner. This causes library loading to fail when using the typelib because its shared-library attribute is wrong.

This is what I found in Gepub-0.6.gir:

<namespace name="Gepub"
           version="0.5"
           shared-library="libgepub/tmp-introspect_7krnj_g/Gepub-0.5:"
           c:identifier-prefixes="Gepub"
           c:symbol-prefixes="gepub">

This kind of wrong values can also be found in GXPS-0.1.gir and GUsb-1.0.gir.

On GNU/Linux, the ldd command provided by glibc doesn't print the input filename to output when only one file is specified, so this problem never happen.

On FreeBSD, DragonflyBSD, NetBSD, OpenBSD, the ldd command always print the input filename before showing the list of libraries, so it is possible for the pattern to match the input filename itself before matching libraries.


Here are some ldd output examples.

GLIBC

$ ldd /usr/bin/uptime
	linux-vdso.so.1 (0x00007ffefeffa000)
	libprocps.so.4 => /lib64/libprocps.so.4 (0x00007feba9118000)
	libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007feba8e8e000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007feba8c8a000)
	libc.so.6 => /lib64/libc.so.6 (0x00007feba88a7000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007feba8688000)
	libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007feba836e000)
	librt.so.1 => /lib64/librt.so.1 (0x00007feba8166000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007feba7f40000)
	liblz4.so.1 => /lib64/liblz4.so.1 (0x00007feba7d2b000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007feba7b02000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007feba78eb000)
	/lib64/ld-linux-x86-64.so.2 (0x00007feba9542000)
	libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007feba76d6000)
	libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007feba7452000)


FreeBSD

$ ldd /usr/bin/uptime
/usr/bin/uptime:
        libkvm.so.7 => /lib/libkvm.so.7 (0x800826000)
        libsbuf.so.6 => /lib/libsbuf.so.6 (0x800a34000)
        libxo.so.0 => /lib/libxo.so.0 (0x800c37000)
        libutil.so.9 => /lib/libutil.so.9 (0x800e54000)
        libc.so.7 => /lib/libc.so.7 (0x801068000)
        libelf.so.2 => /lib/libelf.so.2 (0x801420000)


DragonflyBSD

$ ldd /usr/bin/uptime
/usr/bin/uptime:
	libkvm.so.3 => /lib/libkvm.so.3 (0x80045a000)
	libc.so.8 => /lib/libc.so.8 (0x800464000)


NetBSD

$ ldd /usr/bin/uptime
/usr/bin/uptime:
        -lkvm.6 => /usr/lib/libkvm.so.6
        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
        -lc.12 => /usr/lib/libc.so.12
        -lutil.7 => /usr/lib/libutil.so.7


OpenBSD

/usr/bin/uptime:
        Start            End              Type Open Ref GrpRef Name
        000001ad50200000 000001ad50405000 exe  1    0   0      /usr/bin/uptime
        000001b0294da000 000001b0296e4000 rlib 0    1   0      /usr/lib/libkvm.so.16.2
        000001af8ed59000 000001af8f039000 rlib 0    1   0      /usr/lib/libc.so.90.0
        000001afe9700000 000001afe9700000 rtld 0    1   0      /usr/libexec/ld.so
Comment 1 Ting-Wei Lan 2017-12-27 18:59:22 UTC
Created attachment 366025 [details] [review]
giscanner: Fix shared library name finding on *BSD

ldd commands on *BSD always print the name of the input file regardless
of the number of arguments, so we have to ignore this line to avoid
matching it with _ldd_library_pattern.
Comment 2 Ting-Wei Lan 2018-01-13 07:37:25 UTC
Ping ... This problem causes gnome-documents to fail to load EPUB files because it cannot load libgepub.
Comment 3 Ting-Wei Lan 2018-01-18 06:51:27 UTC
Ping again ... I think this is a trivial patch which should not take much time to review.
Comment 4 Emmanuele Bassi (:ebassi) 2018-01-20 10:55:22 UTC
Review of attachment 366025 [details] [review]:

Okay
Comment 5 Ting-Wei Lan 2018-01-20 12:04:23 UTC
Attachment 366025 [details] pushed as f9788b2 - giscanner: Fix shared library name finding on *BSD