I wanted to test this beforehand but Christmas got in the way. I'm
testing the contents of the 2.70 branch now and it's looking good, so
thanks very much!
Ross
On Wed, 23 Dec 2020 at 19:21, Zack Weinberg wrote:
>
> On Sun, Dec 20, 2020 at 12:09 PM Zack Weinberg wrote:
> > I'm not happy about
On Sun, Dec 20, 2020 at 12:09 PM Zack Weinberg wrote:
> I'm not happy about needing to kludge backward compatibility with the
> older std-gnu11.m4 into autoconf 2.70.1 but I'm going to do it.
As of commit 2d0f19d84ddb13412382674fd48e6fc5c2875d0e, Autoconf
*trunk* should now be backward
On Sun, Dec 20, 2020 at 12:09 PM Zack Weinberg wrote:
> I'm not happy about needing to kludge backward compatibility with the
> older std-gnu11.m4 into autoconf 2.70.1 but I'm going to do it.
It occurs to me that this would be less of a problem in the future if
aclocal/autoreconf could update
On Sun, Dec 20, 2020 at 11:54 AM Ross Burton wrote:
> On Sun, 20 Dec 2020 at 16:46, Bruno Haible wrote:
>> This patch is already in Gnulib since 2020-12-09. But when people
>> run 'autoreconf' on an existing released tarball, they are effectively
>> combining an older Gnulib with a newest
On Sun, Dec 20, 2020 at 11:46 AM Bruno Haible wrote:
>
> Zack Weinberg wrote:
> > $ diff -u m4/std-gnu11.m4{~,}
> > --- m4/std-gnu11.m4~2020-08-30 11:27:01.0 -0400
> > +++ m4/std-gnu11.m42020-12-20 09:43:13.001477099 -0500
> > @@ -27,6 +27,8 @@
> > # François Pinard, Karl Berry,
On Sun, 20 Dec 2020 at 16:46, Bruno Haible wrote:
> This patch is already in Gnulib since 2020-12-09. But when people
> run 'autoreconf' on an existing released tarball, they are effectively
> combining an older Gnulib with a newest Autoconf.
>
> Why do people do that? The point of tarballs is
Zack Weinberg wrote:
> $ diff -u m4/std-gnu11.m4{~,}
> --- m4/std-gnu11.m4~2020-08-30 11:27:01.0 -0400
> +++ m4/std-gnu11.m42020-12-20 09:43:13.001477099 -0500
> @@ -27,6 +27,8 @@
> # François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
> # Roland McGrath, Noah
On Wed, Dec 16, 2020 at 4:55 PM Todd C. Miller wrote:
>
> ./config.status: line 556: syntax error at line 562: `<<' unmatched
Could you please clarify exactly which program's configure script gave
this error?
zw
On Wed, Dec 16, 2020 at 2:02 PM Zack Weinberg wrote:
> On Wed, Dec 16, 2020 at 1:52 PM Ross Burton wrote:
> > | checking for gcc option to enable C11 features... none needed
> > | ../bison-3.7.4/configure: line 6187: syntax error near unexpected
> > token `ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89'
On Wed, 16 Dec 2020 14:48:19 -0600, Bob Friesenhahn wrote:
> On Wed, 16 Dec 2020, Todd C. Miller wrote:
> >
> > Perhaps you are hitting this bug that breaks C99 flag detection?
> >https://savannah.gnu.org/support/?110396
>
> What are the impacts of that?
The impact is that the configure
On Wed, 16 Dec 2020, Todd C. Miller wrote:
Perhaps you are hitting this bug that breaks C99 flag detection?
https://savannah.gnu.org/support/?110396
What are the impacts of that?
I just opened this new one. Is it related?
sr #110403: autoconf-2.70 AC_TYPE_INTMAX_T test failure under
On Wed, 16 Dec 2020 17:04:31 +, Ross Burton wrote:
> All through the 2.70 prelease cycle I was periodically running builds
> of OpenEmbedded with the snapshots as they were released. As we
> autoreconf by default this was great at shaking out some bugs in both
> packages and autoconf itself.
On Wed, Dec 16, 2020 at 1:52 PM Ross Burton wrote:
> | checking for gcc option to enable C11 features... none needed
> | ../bison-3.7.4/configure: line 6187: syntax error near unexpected
> token `ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89'
> | ../bison-3.7.4/configure: line 6187: `
>
On Wed, 16 Dec 2020 at 18:05, Zack Weinberg wrote:
> First, could you please test whether the problem is already fixed in
> branch-2.70? The release went out with an embarrassing typo in this
> code. I was waiting to hear back from the automake people about some
> problems running their
On Wed, Dec 16, 2020 at 12:22 PM Ross Burton wrote:
> All through the 2.70 prelease cycle I was periodically running builds
> of OpenEmbedded with the snapshots as they were released. As we
> autoreconf by default this was great at shaking out some bugs in both
> packages and autoconf itself.
Hi,
All through the 2.70 prelease cycle I was periodically running builds
of OpenEmbedded with the snapshots as they were released. As we
autoreconf by default this was great at shaking out some bugs in both
packages and autoconf itself. However, I see that in between the
Release Candidate and
16 matches
Mail list logo
