newlib not building (needs aclocal)
Richard Earnshaw
Richard.Earnshaw@foss.arm.com
Wed Feb 23 11:33:01 GMT 2022
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.
More information about the Newlib
mailing list