Fix g-ir-scanner when the build directory contains the library name
On OpenBSD we noticed a number of .gir
files that had an incorrect shared-library
field, along the lines of
shared-library="libgweather-3.28.1/build-amd64/tmp-introspecteuljis0a/GWeather-3.0"
Where the expected value would be:
shared-library="libgweather-3.so.3.2"
This would result for example in:
% gnome-weather
** (org.gnome.Weather.Application:64013): WARNING **: 20:20:49.321: Failed to load shared library 'libgweather-3.28.1/build-amd64/tmp-introspectxzu3sbot/GWeat
(org.gnome.Weather.Application:64013): Gjs-WARNING **: 20:20:49.321: JS ERROR: Error: Unsupported type void, deriving from fundamental void
@resource:///org/gnome/Weather/Application/js/shared/world.js:31:54
@resource:///org/gnome/Weather/Application/js/app/window.js:26:7
@resource:///org/gnome/Weather/Application/js/app/main.js:36:7
@/usr/local/bin/gnome-weather:6:1
Script /usr/local/bin/gnome-weather threw an exception
Also affected are at least libical and libgepub.
The problem turned out to be that the first actual line of ldd
output contains the "new library", e.g. libgweather-3.28.1/build-amd64/tmp-introspecteuljis0a/GWeather-3.0
instead of the actual library name. However for ports where the library name would be part of the full path, we'd incorrectly match on this line and end up with a bogus shared-library
value added to shlibs
. The next line would be the one we'd want, but by then the pattern has been removed from patterns
and shlibs
was returned.
As a workaround we're skipping the first three lines on OpenBSD now, to make sure skip over the header (harmless) and the exe
line (deemed not so harmless). Therefore the first hit parses correctly and we have the correct library. This is certainly not the correct "fix" but allows us to move forward. I've attached our patch and feedback is welcome on how to rework this in order to make it submittable.