require autoconf-2.69 exactly

R. Diez
Wed Jan 12 20:01:01 GMT 2022

> The newlib & libgloss dirs are already generated using autoconf-2.69.
> To avoid merging new code and/or accidental regeneration using diff
> versions, leverage config/override.m4 to pin to 2.69 exactly.  This
> matches what gcc/binutils/gdb are already doing.

Pinning to exactly version 2.69 is a strange thing to do.

I have been using Autoconf 2.69 for years in my embedded firmware project, and when 2.70 and 2.71 came out not long ago, I upgraded without any 
trouble. They also bring a raft of general improvements.

Is there a reason why Newlib must be exactly be in sync with whatever GCC etc. do?

The regeneration problems you have every now and then are a consequence of checking in the files that the Autotools generate. You are not supposed to 
do that. Anybody directly using a source code repository should be running some bootstrap script, perhaps with a common name like, in order 
to generate the Autotools files first.

The release tarballs you generate here should include the generated Autotools files:

That is, assuming you could actually access an FTP server with a modern browser.

I am sure you know that this is standard practice with the Autotools. I can imagine some delay implementing it until the whole Autotools mess in 
Newlib has been cleaned up (which is a great thing to do, by the way). But pinning to an exact Autoconf version seems like a step in the wrong direction.


More information about the Newlib mailing list