Re: bison segv under Cygwin 64 at fatal-signal.c:318
On 2021-09-23 21:28, Akim Demaille wrote: Hi Brian, [dropping bug-gnulib] Le 23 sept. 2021 à 19:54, Brian Inglis 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:Bug href="https://github.com/doxygen/doxygen/issues/5559";>5559 - plantUML requires epstopdf for building PDF files [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. Santé! -- 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.]
Re: bison segv under Cygwin 64 at fatal-signal.c:318
Hi Brian, [dropping bug-gnulib] > Le 23 sept. 2021 à 19:54, Brian Inglis 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. Cheers!
Re: bison segv under Cygwin 64 at fatal-signal.c:318
On 2021-09-20 21:25, Akim Demaille wrote: Le 18 sept. 2021 à 19:04, Brian Inglis a écrit : Thanks very much for your help Bruno, in diagnosing the issue correctly, and providing the patch: I will ensure your patch comment gets prefixed into the respun bison gnulib patch. And thanks Akim for getting Bruno involved to address the right area. Cygwin bison users will be happy having the latest build available. I did not see the confirmation that the last tarball I made did work on your system. https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.1.29-5c106.tar.gz https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.1.29-5c106.tar.lz https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.1.29-5c106.tar.xz I might have missed it though. Sorry Akim, I thought it was understood as confirmed in my last message. 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. Your interim release includes the gnulib threadlib.m4 patch, so I had to disable applying that, which is great. 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. Thanks very much again to you both, the great help is appreciated. -- 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.]
Re: 'make clean' not working
> On 23 Sep 2021, at 18:42, Akim Demaille wrote: > >> Le 23 sept. 2021 à 09:31, Hans Åberg a écrit : >> >>> I can't reproduce your problem. I have run configure, make, make clean, >>> make, without any problem (autoconf was not called). Maybe something was >>> touched in your tree, I don't know. >> >> I can reproduce the problem by modifying a file by touching it after the >> build (tried with an m4 file) and making sure autoconf is not in the PATH. > > That's expected: if you touch something that requires Autoconf, of course > autoconf is fired. > > Andrea said he did nothing like that, yet autoconf was called. Then it does not happen here: I moved a file, made a copy to the original name, and the problem showed. Then I deleted the copy, and moved the original back, and then it did not happen.
Re: 'make clean' not working
> Le 23 sept. 2021 à 09:31, Hans Åberg a écrit :
>
>>
>> On 23 Sep 2021, at 07:31, Akim Demaille wrote:
>>
>> Hi Andrea,
>>
>>> Le 21 sept. 2021 à 16:45, Andrea Monaco a
>>> écrit :
>>>
>>> Hello,
>>>
>>> I'm trying to rebuild a bison-3.8 release tree, but "make clean" aborts
>>> with this error:
>>>
>>> CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
>>> '/root/bison-3.8/build-aux/missing' autoconf
>>> /root/bison-3.8/build-aux/missing: line 81: autoconf: command not found
>>> WARNING: 'autoconf' is missing on your system.
>>> You should only need it if you modified 'configure.ac',
>>> or m4 files included by it.
>>> The 'autoconf' program is part of the GNU Autoconf package:
>>>
Re: 'make clean' not working
> On 23 Sep 2021, at 07:31, Akim Demaille wrote:
>
> Hi Andraea,
>
>> Le 21 sept. 2021 à 16:45, Andrea Monaco a
>> écrit :
>>
>> Hello,
>>
>> I'm trying to rebuild a bison-3.8 release tree, but "make clean" aborts
>> with this error:
>>
>> CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
>> '/root/bison-3.8/build-aux/missing' autoconf
>> /root/bison-3.8/build-aux/missing: line 81: autoconf: command not found
>> WARNING: 'autoconf' is missing on your system.
>>You should only need it if you modified 'configure.ac',
>>or m4 files included by it.
>>The 'autoconf' program is part of the GNU Autoconf package:
>>
