newlib not building (needs aclocal)

newlib not building (needs aclocal)

[Richard Earnshaw]

Mike,

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.

[PATCH/committed] libgloss: enable maintainer mode support

[Mike Frysinger]

Use AM_MAINTAINER_MODE so devs have to opt-in to automatic rebuilds
of autotools.  This matches what newlib (and most every other GNU
toolchain package) does with automake.
---
 libgloss/Makefile.in  |  9 +++++----
 libgloss/aclocal.m4   | 36 ++++++++++++++++++++++++++++++++++++
 libgloss/configure    | 34 ++++++++++++++++++++++++++++++++++
 libgloss/configure.ac |  1 +
 4 files changed, 76 insertions(+), 4 deletions(-)

diff --git a/libgloss/configure.ac b/libgloss/configure.ac
index b5a0fce08c9b..ec2a49e03704 100644
--- a/libgloss/configure.ac
+++ b/libgloss/configure.ac
@@ -12,6 +12,7 @@ AC_PROG_INSTALL
 
 AC_CANONICAL_SYSTEM
 AM_INIT_AUTOMAKE([foreign no-dist no-define subdir-objects 1.15.1])
+AM_MAINTAINER_MODE
 AM_SILENT_RULES(yes)
 
 if test -z "${with_multisubdir}"; then
-- 
2.34.1

Re: [PATCH/committed] libgloss: enable maintainer mode support

[Richard Earnshaw]

Thanks, Mike.

On 22/02/2022 22:11, Mike Frysinger wrote:
> Use AM_MAINTAINER_MODE so devs have to opt-in to automatic rebuilds
> of autotools.  This matches what newlib (and most every other GNU
> toolchain package) does with automake.
> ---
>   libgloss/Makefile.in  |  9 +++++----
>   libgloss/aclocal.m4   | 36 ++++++++++++++++++++++++++++++++++++
>   libgloss/configure    | 34 ++++++++++++++++++++++++++++++++++
>   libgloss/configure.ac |  1 +
>   4 files changed, 76 insertions(+), 4 deletions(-)
> 
> diff --git a/libgloss/configure.ac b/libgloss/configure.ac
> index b5a0fce08c9b..ec2a49e03704 100644
> --- a/libgloss/configure.ac
> +++ b/libgloss/configure.ac
> @@ -12,6 +12,7 @@ AC_PROG_INSTALL
>   
>   AC_CANONICAL_SYSTEM
>   AM_INIT_AUTOMAKE([foreign no-dist no-define subdir-objects 1.15.1])
> +AM_MAINTAINER_MODE
>   AM_SILENT_RULES(yes)
>   
>   if test -z "${with_multisubdir}"; then

Re: newlib not building (needs aclocal)

[Brian Inglis]

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?

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?

-- 
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: newlib not building (needs aclocal)

[Richard Earnshaw]

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.

Re: newlib not building (needs aclocal)

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 3224 bytes --]

On 23 Feb 2022 11:33, Richard Earnshaw wrote:
> On 23/02/2022 06:01, Brian Inglis wrote:
> > On 2022-02-22 04:57, Richard Earnshaw wrote:
> >> 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.

i think this is conflating things a bit.  tot testing gcc against tot newlib
is helpful for both projects.  we want that.

but if gcc is preparing a release branch, it should be freezing against a
specific newlib tag (the latest at the time of that branch cut).  users of
a gcc release will also be grabbing newlib releases and expecting that they
work together.

that might mean there's still disruption for devs during the release cycle --
tot gcc hadn't been tested against the latest newlib release previously, so
bugs could pop up.  but users are going to see those same bugs, so it's not
like they're "false" failures.

throwing builders at it would help (have tot test against tot newlib and the
last newlib release), but i suspect that isn't worth the effort for the same
reasons you mention -- the project normally doesn't move that fast, and the
number of active devs is kind of low.

> > 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.

practically speaking, i don't think topic branches would help that much as
you highlight -- the newlib project, and number of projects/devs, is much
too small to get a good signal back.

it would require people to opt-in to the branch, as well as configure the
various builders out there to use it.  that seems pretty unlikely.  which
means once the topic branch is merged back into master, everything blows
up.  except instead of little scattered fires that are easier to pin to
specific commit ranges, everything is on fire, perhaps for more than one
reason, and requires multiple bisects over weeks/months of work.

i'd like to think that for the regressions i've introduced (and fixed),
i've made up for it with better comments & documentation.  so the next
person who touches things doesn't fall into the same pits.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: newlib not building (needs aclocal)

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On 24 Feb 2022 02:07, Mike Frysinger wrote:
> practically speaking, i don't think topic branches would help that much as
> you highlight -- the newlib project, and number of projects/devs, is much
> too small to get a good signal back.

which isn't to say i'm against them.  i asked in a previous thread a while
back about newlib policies around creating branches like this so i could
push my local state for people to peek at, but didn't get a response.  so
i assumed it was undesired or not allowed.

at this point, i've got maybe 5 patches for libgloss (update toolchain
settings as has been done in newlib already) & 5 for newlib (finish libc
conversion to top-level like libm) before i call it quits.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: newlib not building (needs aclocal)

[Corinna Vinschen]

On Feb 24 02:11, Mike Frysinger wrote:
> On 24 Feb 2022 02:07, Mike Frysinger wrote:
> > practically speaking, i don't think topic branches would help that much as
> > you highlight -- the newlib project, and number of projects/devs, is much
> > too small to get a good signal back.
> 
> which isn't to say i'm against them.  i asked in a previous thread a while
> back about newlib policies around creating branches like this so i could
> push my local state for people to peek at, but didn't get a response.  so
> i assumed it was undesired or not allowed.

You can create and destroy topic branches, e.g.

  git checkout -b topic/drop-all-32bit-targets

These can be force pushed and generally worked on without generating
mails to newlib-cvs.  We're using them in Cygwin as well if something
isn't supposed to go into master just yet.


Corinna