Re: bison segv under Cygwin 64 at fatal-signal.c:318

Brian Inglis <[email protected]> Fri, 24 Sep 2021 20:30:25 -0600
Newsgroups gmane.comp.parsers.bison.bugs
Organization Systematic Software
Message-ID <[email protected]>
On 2021-09-24 00:06, Brian Inglis wrote:
> On 2021-09-23 21:28, Akim Demaille wrote:
>> Hi Brian, [dropping bug-gnulib]
>>
>>> Le 23 sept. 2021 à 19:54, Brian Inglis 
>>> <[email protected]> a écrit :
>>>
>>> Sorry Akim,
>>>
>>> I thought it was understood as confirmed in my last message.
>>
>> You might very well have, but I didn't see it.  I saw a confirmation 
>> of success of a tarball that I interpreted as referring to Bruno's 
>> testdir-thread, but maybe you meant bison.
>>
>>
>>> This month I am busy dealing with a number of maintained package 
>>> upgrade build and test failures, and at least one other appears to 
>>> also be due to an obscure gnulib upgrade, after years of upgrades 
>>> with at most only the occasional package tweak required, requiring 
>>> only basic knowledge of autotools and none of gnulib!
>>> With each build requiring one or more hours for the package manager 
>>> to configure && make && make VPATH install && make check locally, for 
>>> each arch, then repeat for confirmation on the CI, it takes up a lot 
>>> of free time.
>>
>> I sure understand this.
>>
>>> Your interim release includes the gnulib threadlib.m4 patch, so I had 
>>> to disable applying that, which is great.
>>
>> Great.  Then we have Bison 3.8.2.  I'll do that this weekend.
>>
>>> Cygwin only needs the revert-autoconf-upgrade patch, until an 
>>> experienced autotools user adopts the autotools as maintainer and 
>>> provides upgrades.
>>>
>>> The builds and tests run completely, and only the Doxygen tests fail, 
>>> although the doc builds work: not a significant concern.
>>
>> I could have a look at that.  Please send the logs.
> 
> No need for you to do that, but you might want to mention the following 
> build/test dependency until doxygen is improved: looked at the tests and 
> doxygen is missing a runtime dependency requirement on epstopdf since 
> 1.8.9 (2014-12-25)!
> 
> It was mentioned in the ChangeLog, but not in other docs.
> 
> $ fgrep -R epstopdf /usr/share/doc/doxygen/
> /usr/share/doc/doxygen/html/changelog.html:<li>Bug <a 
> href="https://github.com/doxygen/doxygen/issues/5559">5559</a> - 
> plantUML requires epstopdf for building PDF files [<a 
> href="https://github.com/doxygen/doxygen/commit/52d216a87451c867c92
> 
> I have commented on the above issue, and requested the runtime 
> dependency requirement be documented, considered during configuration, 
> and checked during testing, as you are doing with doxygen.
> 
> I have installed the prerequisite package containing epstopdf, will add 
> it as a build dependency, rerun the tests again, and redo the CI builds, 
> just to get some clean logs!
> 
> The package containing epstopdf is an optional part of texlive called 
> variously things like texlive-fontutils, texlive-font-utils, 
> texlive-collection-fontutils, etc.

Rebuilt both latest and prerelease versions again, and all tests passed, 
except 58 tests skipped as always, mainly D and Java.

-- 
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 binary units and prefixes, physical quantities in SI.]