On 6/11/2020 5:39 PM, Jon Turney wrote:
On 06/06/2020 15:15, Ken Brown via Cygwin-apps wrote:
I think I might have bumped into another meson/introspection/pickling bug,
this time in connection with harfbuzz. The supported build system for
harfbuzz is still autotools. But they're planning to move to meson, so I
decided to get a head start and try the meson build, which fails as follows:
[230/257] Generating HarfBuzz-0.0.gir with a meson_exe.py custom command
FAILED: src/HarfBuzz-0.0.gir
/usr/bin/meson --internal exe --unpickle
/tmp/harfbuzz-2.6.7/build/meson-private/meson_exe_g-ir-scanner_2a1d762c64dc7a0dcba76211733b53a4f7f14918.dat
[...]
ERROR: can't resolve libraries to shared libraries: harfbuzz-gobject
g-ir-scanner: link: cc -o
/tmp/harfbuzz-2.6.7/build/tmp-introspectKdIYKJ/HarfBuzz-0.0.exe
/tmp/harfbuzz-2.6.7/build/tmp-introspectKdIYKJ/HarfBuzz-0.0.o -L. -lharfbuzz
-lharfbuzz-gobject -lm -lglib-2.0 -lintl -lgobject-2.0 -lcairo -lfreetype
-lgraphite2 -lfontconfig -L/tmp/harfbuzz-2.6.7/build/src
-Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src -L/tmp/harfbuzz-2.6.7/build/src
-Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src -L/tmp/harfbuzz-2.6.7/build/src
-Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src -lgio-2.0 -lgobject-2.0
-Wl,--export-all-symbols -lgmodule-2.0 -lglib-2.0 -lintl
[...]
Thanks for the reproduction steps.
To debug: hack meson to get it to disgorge the pickled command it's executing,
then you can run the failing g-ir-scanner command line while poking at things in
/usr/lib/gobject-introspection/giscanner/
This actually looks like a bug in 'g-ir-scanner --no-libtool' (which obviously
isn't usually exercised by an autotools build), failing in this particular case.
It looks to match the following list of regexes:
([^\s]*cyg*harfbuzz[^A-Za-z0-9_][^\s\(\)]*)
([^\s]*cyg*harfbuzz\-gobject[^A-Za-z0-9_][^\s\(\)]*)
against ldd output like this, to extract the shared library names:
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff916d8)
KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
(0x7ff91666)
KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
(0x7ff914a2)
cyggmodule-2.0-0.dll => /usr/bin/cyggmodule-2.0-0.dll (0x3e059)
cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
cygharfbuzz-gobject-0.dll =>
/work/harfbuzz-2.6.7/_build/src/cygharfbuzz-gobject-0.dll (0x4389e)
cyggio-2.0-0.dll => /usr/bin/cyggio-2.0-0.dll (0x3e0f4)
cygglib-2.0-0.dll => /usr/bin/cygglib-2.0-0.dll (0x3e087)
cyggobject-2.0-0.dll => /usr/bin/cyggobject-2.0-0.dll (0x3dff5)
cygharfbuzz-0.dll => /work/harfbuzz-2.6.7/_build/src/cygharfbuzz-0.dll
(0x4408d)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3cf15)
cygz.dll => /usr/bin/cygz.dll (0x3bc75)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3dbec)
cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x4629a)
cygffi-6.dll => /usr/bin/cygffi-6.dll (0x3e3fd)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x50caa)
cygfreetype-6.dll => /usr/bin/cygfreetype-6.dll (0x45172)
cyggraphite2-3.dll => /usr/bin/cyggraphite2-3.dll (0x5f6ba)
cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3e998)
cygpng16-16.dll => /usr/bin/cygpng16-16.dll (0x3c58d)
cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x57b19)
Unfortunately, the first regex matches the cygharfbuzz-gobject line, leaving the
second regex unmatched.
We have to allow a '-' to appear after the library name, as that introduces a
soversion, so I worked around this by patching
/usr/lib/gobject-introspection/giscanner/shlibs.c like this:
--- shlibs.py~ 2018-02-11 23:15:03.0 +
+++ shlibs.py 2020-06-11 22:28:07.901294700 +0100
@@ -62,7 +62,7 @@
if platform.system() == 'Darwin':
pattern = "([^\s]*lib*%s[^A-Za-z0-9_-][^\s\(\)]*)"
elif platform.platform().startswith('CYGWIN'):
- pattern = "([^\s]*cyg*%s[^A-Za-z0-9_][^\s\(\)]*)"
+ pattern = "([^\s]*cyg%s[-.0-9]*\.[^\s\(\)]*)"
return re.compile(pattern % re.escape(library_name))
But this all seems very fragile though, so I'm not sure if that's the right way
to fix this.
Jon,
No one has suggested a better fix, so I think we should get your fix into the
distro. It's not urgent, because harfbuzz still supports both autotools and
meson, but they're encouraging packagers to move toward meson.
How do you think we should proceed? Are you interested in adopting
gobject-introspection? Alternatively, one of us could do a non-maintainer
upload while we wait for a volunteer.
Ken
