public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Ken Brown <kbrown@cornell.edu>
To: cygwin-apps@cygwin.com
Subject: Re: Help needed with gobject-introspection
Date: Thu, 11 Jun 2020 19:23:03 -0400	[thread overview]
Message-ID: <070a6a40-a1f4-c17e-3da6-3541174c5ec5@cornell.edu> (raw)
In-Reply-To: <4345fbc7-0c30-9335-46a8-bfe2ae79a8bc@dronecode.org.uk>

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 (0x7ff916d80000)
>>         KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL 
>> (0x7ff916660000)
>>         KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll 
>> (0x7ff914a20000)
>>         cyggmodule-2.0-0.dll => /usr/bin/cyggmodule-2.0-0.dll (0x3e0590000)
>>         cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
>>         cygharfbuzz-gobject-0.dll => 
>> /work/harfbuzz-2.6.7/_build/src/cygharfbuzz-gobject-0.dll (0x4389e0000)
>>         cyggio-2.0-0.dll => /usr/bin/cyggio-2.0-0.dll (0x3e0f40000)
>>         cygglib-2.0-0.dll => /usr/bin/cygglib-2.0-0.dll (0x3e0870000)
>>         cyggobject-2.0-0.dll => /usr/bin/cyggobject-2.0-0.dll (0x3dff50000)
>>         cygharfbuzz-0.dll => /work/harfbuzz-2.6.7/_build/src/cygharfbuzz-0.dll 
>> (0x4408d0000)
>>         cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3cf150000)
>>         cygz.dll => /usr/bin/cygz.dll (0x3bc750000)
>>         cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3dbec0000)
>>         cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x4629a0000)
>>         cygffi-6.dll => /usr/bin/cygffi-6.dll (0x3e3fd0000)
>>         cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x50caa0000)
>>         cygfreetype-6.dll => /usr/bin/cygfreetype-6.dll (0x451720000)
>>         cyggraphite2-3.dll => /usr/bin/cyggraphite2-3.dll (0x5f6ba0000)
>>         cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3e9980000)
>>         cygpng16-16.dll => /usr/bin/cygpng16-16.dll (0x3c58d0000)
>>         cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x57b190000)
> 
> 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.000000000 +0000
> +++ 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.
> 
> (This 'if cygwin' case is coming from gobject-introspection package in [1], it's 
> not in upstream)
> 
> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gobject-introspection.git;a=blob;f=1.46.0-cygwin.patch;h=a03271ea17e0d167eba7627ddf5d4303bbde9871;hb=4e3b8bd140db78ee35f29ee3d07ff3715416e259#l93 

Thanks, Jon!  Just as your mail came in, I was staring at the regex for 
harfbuzz-gobject in shlibs.py, trying to understand why it wasn't matched.  It 
never occurred to me that the cygharfbuzz-gobject-0.dll line in the ldd output 
was being used to match the regex for harfbuzz rather than the one for 
harfbuzz-gobject.  What a mess.

Thanks again.

Ken

  reply	other threads:[~2020-06-11 23:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 23:04 Ken Brown
2020-05-20 14:50 ` Ken Brown
2020-05-21 13:24   ` Jon Turney
2020-05-21 15:13     ` Ken Brown
2020-05-21 15:48       ` Jon Turney
2020-05-21 17:07         ` Ken Brown
2020-05-24 15:56           ` Jon Turney
2020-05-24 16:45             ` Ken Brown
2020-05-24 17:00               ` Ken Brown
2020-05-25 15:04                 ` Ken Brown
2020-05-29 15:56                   ` Jon Turney
2020-05-27 20:32             ` Ken Brown
2020-05-29 15:54               ` Jon Turney
2020-05-31 20:52                 ` Jon Turney
2020-05-31 23:58                   ` Ken Brown
2020-06-01 11:30                     ` Jon Turney
2020-06-02 14:26                       ` Jon Turney
2020-06-02 14:31                         ` Ken Brown
2020-06-02 21:28                           ` Jon Turney
2020-06-03 16:51                             ` Jon Turney
2020-06-03 18:30                               ` Ken Brown
2020-06-06 14:15                                 ` Ken Brown
2020-06-11 21:39                                   ` Jon Turney
2020-06-11 23:23                                     ` Ken Brown [this message]
2020-06-12 14:44                                       ` Jon Turney
2020-08-01 18:01                                     ` Ken Brown
2020-08-01 18:34                                       ` Jon Turney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=070a6a40-a1f4-c17e-3da6-3541174c5ec5@cornell.edu \
    --to=kbrown@cornell.edu \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).