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.]