Re: newlib not building (needs aclocal)

On 23/02/2022 06:01, Brian Inglis wrote:
> On 2022-02-22 04:57, Richard Earnshaw wrote:
> 
>> I think something you've changed is forcing the newlib build to now 
>> need a local installation of automake.  This wasn't needed before 
>> unless you were updating the makefiles locally.
>>
>> CDPATH="${ZSH_VERSION+.}:" && cd [...]/libgloss && /bin/bash 
>> [...]/missing aclocal-1.15 -I . -I .. -I ../config
>> [...]/missing: line 81: aclocal-1.15: command not found
>> WARNING: 'aclocal-1.15' is missing on your system.
>>           You should only need it if you modified 'acinclude.m4' or
>>           'configure.ac' or m4 files included by 'configure.ac'.
>>
>> Did you leave something out of a commit somewhere?  If not, how can 
>> this be fixed so that we don't need automake during normal builds from 
>> the repo?
>>
>> R.
>>
>> PS While I appreciate what you're trying to do here, the timing 
>> couldn't be worse given that we're trying to stabilize a GCC release 
>> and all my builds are breaking at present.
> 
> If you need stability, shouldn't you freeze your newlib pull at year end 
> 4.2.0 20211231 484d2eb snapshot, earlier about 2021-09-06 522cdab, just 
> before Mike started his optimization and cleanup marathon, or maybe add 
> an arm-gcc-dev(-11?) tag at some point in there?


Well for testing gcc-12 a freeze for gcc-11 is not very helpful.  Newlib 
doesn't have release branches (not really sure why not, especially when 
there are potential security issues to deal with), and while I could 
freeze against specific tags, that would mean I never test tip-of-tree 
newlib.

Fortunately, over the years newlib has been very stable and it has been 
rare for there to be much breakage (at least, breakage that prevents 
building at all).

> 
> Do you think perhaps devs doing extended or extensive work should create 
> their own newlib, topic, or remote tracking branches (as Cygwin devs do 
> for major work - see summary page heads or git ls-remote --heads 
> --sort=-creatordate | head) and commit work there, perhaps merging back 
> to master at intermediate points, or even not until complete?
> 

There might be a case for this, particularly for disruptive changes. 
It's a matter of balance, given the size of the newlib project.

As I said before, I fully support modernizing newlib's make structure, 
it's just a little unfortunate that it's being done during the run-up to 
gcc-12.

R.