GNOME Bugzilla – Bug 791991
Broken shared-library value in gir files on *BSD when builddir includes the name of the library
Last modified: 2018-01-20 12:04:26 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
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.
Ping ... This problem causes gnome-documents to fail to load EPUB files because it cannot load libgepub.
Ping again ... I think this is a trivial patch which should not take much time to review.
Review of attachment 366025 [details] [review]: Okay
Attachment 366025 [details] pushed as f9788b2 - giscanner: Fix shared library name finding on *BSD