On 2020-06-09 07:26, Jon Turney wrote:
> On 04/06/2020 21:33, Brian Inglis wrote:
>> On 2020-06-04 10:01, Ken Brown via Cygwin-apps wrote:
>>> On 5/27/2020 6:27 PM, Jon Turney wrote:
>>>> On 04/08/2019 21:08, Jon Turney wrote:
>>>>> To remedy this lack, using the same ssh key you use for sftp package
>>>>> upload,
>>>>> package maintainers can now also push to git repositories, like so:
>>>> Package maintainers may have noticed that the output from pushing to these
>>>> git
>>>> repositories now includes a line like:
>>>> "remote: scallywag: build nnn queued"
>>>> This is a *prototype* of a system to automatically build the packages,
>>>> where
>>>> the results appear (some time later) at [1] (URL subject to change)
>>>> [1] https://cygwin.com/cgi-bin2/jobs.cgi
>>
>>> This is great! Thanks for doing this. One strange thing I've noticed is
>>> that
>>> sometimes a package will build fine on x86_64 but will fail on x86 with an
>>> error
>>> like this:
>>> distutils.errors.CompileError: command 'gcc' terminated by signal 11
>>> make[4]: ***
>>> [/usr/share/gobject-introspection-1.0/Makefile.introspection:160:
>>> HarfBuzz-0.0.gir] Error 1
>>> Every time I've seen this, the build works fine on my local x86 install, so
>>> it's
>>> not a big deal. But I'm curious what might cause this.
>>
>> $ kill -l 11
>> SEGV
>>
>> distutils bug?
>
> There should be no input that distutils can give gcc that makes it SEGV, so
> it's
> at least a gcc bug as well.
>
> I've adjusted things so any .stackdump files created by the build should be
> preserved, which might give a start at investigating this.
Any chance it may have a similar or related cause to:
https://bugzilla.redhat.com/show_bug.cgi?id=1737186#c11
"I went ahead and enabled the introspection build. The issue that was causing
the introspection scanner to not find libharfbuzz-gobject.so.0 was that the spec
file was removing the rpaths that the introspection scanner relies on."
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
