GNU make 4.2.90 release candidate available

classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

GNU make 4.2.90 release candidate available

Paul Smith-20
    --------------------------------------------------------------------
    GNU make is a tool which controls the generation of executables and
    other non-source files of a program from the program's source files.

    You can learn more at: https://www.gnu.org/software/make/
    --------------------------------------------------------------------

A new release candidate for GNU make 4.3 is available now for download:

    36083ab822b50a9ecbf5467cdadff55c  make-4.2.90.tar.bz2
    e2c9abdeaf3725f8654a5e9d7a121fa9  make-4.2.90.tar.gz

You can obtain a copy from:  https://alpha.gnu.org/gnu/make/

- NEWS ----------------------------------------------------------------

Version 4.2.90 (26 Aug 2019)

A complete list of bugs fixed in this version is available here:

https://sv.gnu.org/bugs/index.php?group=make&report_id=111&fix_release_id=108&set=custom

* WARNING: Backward-incompatibility!
  Number signs (#) appearing inside a macro reference or function invocation
  no longer introduce comments and should not be escaped with backslashes:
  thus a call such as:
    foo := $(shell echo '#')
  is legal.  Previously the number sign needed to be escaped, for example:
    foo := $(shell echo '\#')
  Now this latter will resolve to "\#".  If you want to write makefiles
  portable to both versions, assign the number sign to a variable:
    H := \#
    foo := $(shell echo '$H')
  This was claimed to be fixed in 3.81, but wasn't, for some reason.
  To detect this change search for 'nocomment' in the .FEATURES variable.

* WARNING: Backward-incompatibility!
  Previously appending using '+=' to an empty variable would result in a value
  starting with a space.  Now the initial space is only added if the variable
  already contains some value.  Similarly, appending an empty string does not
  add a trailing space.

* WARNING: Backward-incompatibility!
  On Linux, and any other systems that provide a /proc/loadavg with similar
  syntax, the -l/--load-average option will use the contents of that file to
  determine how many jobs are running at any given instant, and compare that
  value to the load value requested.  This allows usage such as "-j -lN" for
  N-processor systems without fear of overload.
  Patch provided by Sven C. Dack <[hidden email]>

* WARNING: Backward-incompatibility!
  Contrary to the documentation, suffix rules with prerequisites were being
  treated BOTH as simple targets AND as pattern rules.  Behavior now matches
  the documentation, and pattern rules are no longer created in this case.

* New feature: Grouped explicit targets
  Pattern rules have always had the ability to generate multiple targets with
  a single invocation of the recipe.  It's now possible to declare that an
  explicit rule generates multiple targets with a single invocation.  To use
  this, replace the ":" token with "&:" in the rule.  To detect this feature
  search for 'grouped-target' in the .FEATURES special variable.
  Implementation contributed by Kaz Kylheku <[hidden email]>

* Makefiles can now specify the '-j' option in their MAKEFLAGS variable and
  this will cause make to enable that parallelism mode.

* GNU make will now use pthread_spawn() on systems where it is available.
  It will select POSIX_SPAWN_USEVFORK where that is available.  If you prefer
  to use fork/exec even on systems where pthread_spawn() is present, you can
  use the --disable-pthread-spawn option to configure.
  Aron Barath <[hidden email]> provided the basic implementation.

* Error messages printed when invoking non-existent commands have been cleaned
  up and made consistent.

* The previous limit of 63 jobs under -jN on MS-Windows is now
  increased to 4095.  That limit includes the subprocess started by
  the $(shell) function.

* A new option --no-silent has been added, that cancels the effect of the
  -s/--silent/--quiet flag.

* A new option -E has been added as a short alias for --eval.

* All wildcard expansion within GNU make, including $(wildcard ...), will sort
  the results.  See https://savannah.gnu.org/bugs/index.php?52076

* Interoperate with newer GNU libc and musl C runtime libraries.

* Performance improvements provided by Paolo Bonzini <[hidden email]>

GNU make Developer News

* Import the GNU standard bootstrap script to replace the hand-rolled
  "make update" method for building code from a GNU make Git repository.

* Rework the source distribution to move source files into the src/*
  subdirectory.  This aligns with modern best practices in GNU.

* Replace local portability code with Gnulib content.  Unfortunately due to a
  problem with Gnulib support for getloadavg, this forces a requirement on
  Automake 1.16 or above in order to build from Git.  See README.git.

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Requiring Automake 1.16.1 due to Gnulib getloadavg?

Paul Eggert
Paul Smith wrote:

> * Replace local portability code with Gnulib content.  Unfortunately due to a
>    problem with Gnulib support for getloadavg, this forces a requirement on
>    Automake 1.16 or above in order to build from Git.  See README.git.

bootstrap.conf and configure.ac say "1.16.1" so presumably NEWS should say
"1.16.1" rather than "1.16".

However, I assume this note refers to the email thread rooted here:

https://lists.gnu.org/r/bug-gnulib/2018-06/msg00024.html

and it's not clear to me what the Gnulib/Automake portability problem is. I
attempted to reproduce the problem on Ubuntu 18.04.3 (which use Automake 1.15.1)
by changing bootstrap.conf and configure.ac to say "1.15.1", but my
'./bootstrap; ./configure --prefix=/tmp/prefix; make check; make install; make
SRCROOTDIR=$HOME/src/gnu ChangeLog; make dist' worked fine. So perhaps the
problem (whatever it is) is not due entirely to Automake version.

For what it's worth, Emacs uses Gnulib getloadavg, but since Emacs switched from
Automake to GNU make in 2017 its build procedure does not require any particular
Automake version. Perhaps GNU Make could start depending on (an older version
of) GNU Make, and take this approach in some future version.

Conversely, Coreutils uses Gnulib getloadavg and still uses Automake, but it
seems to work fine requiring only Automake 1.11.2 or later. Perhaps this is
because Coreutils switched to non-recursive 'make' in 2012. This might be
another approach GNU Make could take.

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 release candidate available

Eli Zaretskii
In reply to this post by Paul Smith-20
> From: Paul Smith <[hidden email]>
> Date: Mon, 26 Aug 2019 09:00:13 -0400
>
> A new release candidate for GNU make 4.3 is available now for download:
>
>     36083ab822b50a9ecbf5467cdadff55c  make-4.2.90.tar.bz2
>     e2c9abdeaf3725f8654a5e9d7a121fa9  make-4.2.90.tar.gz
>
> You can obtain a copy from:  https://alpha.gnu.org/gnu/make/

Thanks.

The file tests/README says to use "perl ./run_make_tests.pl" on
Windows, but then what is the file run_make_tests.bat for?  It seems
to do the same, but it also accepts argument.  How are these arguments
used -- can I run just a specific test, for example?

(I didn't yet have time to look closely at the files, so maybe some of
these questions have easy answers, sorry.)

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 release candidate available

Paul Smith-20
On Mon, 2019-08-26 at 19:26 +0300, Eli Zaretskii wrote:

> > From: Paul Smith <[hidden email]>
> > Date: Mon, 26 Aug 2019 09:00:13 -0400
> >
> > A new release candidate for GNU make 4.3 is available now for
> > download:
> >
> >      36083ab822b50a9ecbf5467cdadff55c  make-4.2.90.tar.bz2
> >      e2c9abdeaf3725f8654a5e9d7a121fa9  make-4.2.90.tar.gz
> >
> > You can obtain a copy from:  https://alpha.gnu.org/gnu/make/
>
> Thanks.
>
> The file tests/README says to use "perl ./run_make_tests.pl" on
> Windows, but then what is the file run_make_tests.bat for?  It seems
> to do the same, but it also accepts argument.  How are these
> arguments used -- can I run just a specific test, for example?

Yes... you can use the .bat I should change the README.

I do it like this:

  cd tests
  .\run_make_tests.bat -make ..\WinRel\gnumake.exe

so it runs the just-built make (else it will run whatever is on your
PATH).

IIRC there may be a failure or two on Windows I can't remember.

To run individual tests you can give the name(s) on the command line.
Note you can only run a whole file, you can't run just specific tests
within a file.


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 release candidate available

David Boyce-3
In reply to this post by Paul Smith-20
Feedback on release notes - there are a couple of things unclear at least to me:

> the -l/--load-average option will use the contents of that file to determine how many jobs are running at any given instant, and compare that value to the load value requested.

Compare and do what? This doesn't make sense to me.

> This allows usage such as "-j -lN" for N-processor systems without fear of overload.

There's never a fear of overload when explicitly specifying -lN for an N-processor system, is there?

> It will select POSIX_SPAWN_USEVFORK where that is available....

Does this mean that the autotools config system will select POSIX_SPAWN_USEVFORK? That's not a behavior of GNU make per se.

On Mon, Aug 26, 2019 at 6:01 AM Paul Smith <[hidden email]> wrote:
    --------------------------------------------------------------------
    GNU make is a tool which controls the generation of executables and
    other non-source files of a program from the program's source files.

    You can learn more at: https://www.gnu.org/software/make/
    --------------------------------------------------------------------

A new release candidate for GNU make 4.3 is available now for download:

    36083ab822b50a9ecbf5467cdadff55c  make-4.2.90.tar.bz2
    e2c9abdeaf3725f8654a5e9d7a121fa9  make-4.2.90.tar.gz

You can obtain a copy from:  https://alpha.gnu.org/gnu/make/

- NEWS ----------------------------------------------------------------

Version 4.2.90 (26 Aug 2019)

A complete list of bugs fixed in this version is available here:

https://sv.gnu.org/bugs/index.php?group=make&report_id=111&fix_release_id=108&set=custom

* WARNING: Backward-incompatibility!
  Number signs (#) appearing inside a macro reference or function invocation
  no longer introduce comments and should not be escaped with backslashes:
  thus a call such as:
    foo := $(shell echo '#')
  is legal.  Previously the number sign needed to be escaped, for example:
    foo := $(shell echo '\#')
  Now this latter will resolve to "\#".  If you want to write makefiles
  portable to both versions, assign the number sign to a variable:
    H := \#
    foo := $(shell echo '$H')
  This was claimed to be fixed in 3.81, but wasn't, for some reason.
  To detect this change search for 'nocomment' in the .FEATURES variable.

* WARNING: Backward-incompatibility!
  Previously appending using '+=' to an empty variable would result in a value
  starting with a space.  Now the initial space is only added if the variable
  already contains some value.  Similarly, appending an empty string does not
  add a trailing space.

* WARNING: Backward-incompatibility!
  On Linux, and any other systems that provide a /proc/loadavg with similar
  syntax, the -l/--load-average option will use the contents of that file to
  determine how many jobs are running at any given instant, and compare that
  value to the load value requested.  This allows usage such as "-j -lN" for
  N-processor systems without fear of overload.
  Patch provided by Sven C. Dack <[hidden email]>

* WARNING: Backward-incompatibility!
  Contrary to the documentation, suffix rules with prerequisites were being
  treated BOTH as simple targets AND as pattern rules.  Behavior now matches
  the documentation, and pattern rules are no longer created in this case.

* New feature: Grouped explicit targets
  Pattern rules have always had the ability to generate multiple targets with
  a single invocation of the recipe.  It's now possible to declare that an
  explicit rule generates multiple targets with a single invocation.  To use
  this, replace the ":" token with "&:" in the rule.  To detect this feature
  search for 'grouped-target' in the .FEATURES special variable.
  Implementation contributed by Kaz Kylheku <[hidden email]>

* Makefiles can now specify the '-j' option in their MAKEFLAGS variable and
  this will cause make to enable that parallelism mode.

* GNU make will now use pthread_spawn() on systems where it is available.
  It will select POSIX_SPAWN_USEVFORK where that is available.  If you prefer
  to use fork/exec even on systems where pthread_spawn() is present, you can
  use the --disable-pthread-spawn option to configure.
  Aron Barath <[hidden email]> provided the basic implementation.

* Error messages printed when invoking non-existent commands have been cleaned
  up and made consistent.

* The previous limit of 63 jobs under -jN on MS-Windows is now
  increased to 4095.  That limit includes the subprocess started by
  the $(shell) function.

* A new option --no-silent has been added, that cancels the effect of the
  -s/--silent/--quiet flag.

* A new option -E has been added as a short alias for --eval.

* All wildcard expansion within GNU make, including $(wildcard ...), will sort
  the results.  See https://savannah.gnu.org/bugs/index.php?52076

* Interoperate with newer GNU libc and musl C runtime libraries.

* Performance improvements provided by Paolo Bonzini <[hidden email]>

GNU make Developer News

* Import the GNU standard bootstrap script to replace the hand-rolled
  "make update" method for building code from a GNU make Git repository.

* Rework the source distribution to move source files into the src/*
  subdirectory.  This aligns with modern best practices in GNU.

* Replace local portability code with Gnulib content.  Unfortunately due to a
  problem with Gnulib support for getloadavg, this forces a requirement on
  Automake 1.16 or above in order to build from Git.  See README.git.
_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: Requiring Automake 1.16.1 due to Gnulib getloadavg?

Paul Smith-20
In reply to this post by Paul Eggert
On Mon, 2019-08-26 at 08:26 -0700, Paul Eggert wrote:
> Paul Smith wrote:
>
> > * Replace local portability code with Gnulib content.  Unfortunately due to a
> >    problem with Gnulib support for getloadavg, this forces a requirement on
> >    Automake 1.16 or above in order to build from Git.  See README.git.
>
> bootstrap.conf and configure.ac say "1.16.1" so presumably NEWS
> should say "1.16.1" rather than "1.16".

OK.

> However, I assume this note refers to the email thread rooted here:
>
> https://lists.gnu.org/r/bug-gnulib/2018-06/msg00024.html
>
> and it's not clear to me what the Gnulib/Automake portability problem
> is.

Agreed.  As far as I know no one every figured it out, Bruno just
suggested moving to the latest and that fixed it.

I just tried this again on Ubuntu 18.04.3, as follows:

  $ automake --version
  automake (GNU automake) 1.15.1

  $ git clean -fdx
  $ ./bootstrap && ./configure && make distcheck
    ...
  make[2]: Leaving directory '/home/psmith/src/make/make/make-4.2.90/_build/sub/doc'
  make[2]: Entering directory '/home/psmith/src/make/make/make-4.2.90/_build/sub'
  Makefile:1126: lib/.deps/getloadavg.Po: No such file or directory
  make[2]: *** No rule to make target 'lib/.deps/getloadavg.Po'.  Stop.
  Makefile:1258: recipe for target 'distclean-recursive' failed
  make[1]: *** [distclean-recursive] Error 1
  Makefile:1466: recipe for target 'distcheck' failed
  make: *** [distcheck] Error 1

It appears that the target that's failing for me, that you didn't try
in your test, is "make distclean".

> For what it's worth, Emacs uses Gnulib getloadavg, but since Emacs
> switched from Automake to GNU make in 2017 its build procedure does
> not require any particular Automake version. Perhaps GNU Make could
> start depending on (an older version of) GNU Make, and take this
> approach in some future version.

GNU make includes a shell script that can be used to build itself so it
doesn't need to rely on an older version of GNU make.

However I'm not excited about replacing all the capabilities provided
by automake, in a hand-rolled set of makefiles.

> Conversely, Coreutils uses Gnulib getloadavg and still uses Automake,
> but it seems to work fine requiring only Automake 1.11.2 or later.
> Perhaps this is because Coreutils switched to non-recursive 'make' in
> 2012. This might be another approach GNU Make could take.

As far as I'm aware, GNU make already uses a non-recursive
configuration of autoconf/automake at least for its own code... that
is, there's only one Makefile.am at the root.

The lib/Makefile.am is created by gnulib.  I'm not sure how to handle
that non-recursively (if it's possible).

I guess I also have po/Makefile.in.in but I'm not sure how to make that
non-recursive either.


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 release candidate available

Paul Smith-20
In reply to this post by David Boyce-3
On Mon, 2019-08-26 at 10:26 -0700, David Boyce wrote:
> > the -l/--load-average option will use the contents of that file to
> determine how many jobs are running at any given instant, and compare
> that value to the load value requested.
>
> Compare and do what? This doesn't make sense to me.

I guess this is confusing.  It means, if there are N processes
currently executing on a core (not waiting) then only start a new job
if -l is >= N (equal to because one active process is make itself so we
don't count it).

> > This allows usage such as "-j -lN" for N-processor systems without
> fear of overload.
>
> There's never a fear of overload when explicitly specifying -lN for
> an N-processor system, is there?

If you use -lN -j, make can kick off enough jobs to kill your system
before the load average can change enough to throttle it.  The most
specific value we can get from getloadavg() is an average over the last
minute.  Admittedly there are other heuristics we try to use to make it
more accurate than that.

> > It will select POSIX_SPAWN_USEVFORK where that is available....
>
> Does this mean that the autotools config system will select
> POSIX_SPAWN_USEVFORK? That's not a behavior of GNU make per se.

Yes, autoconf will detect and use it.  I'm not sure I understand the
comment.


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 release candidate available

David Boyce-3
> I guess this is confusing ...

There may be confusion in the text between "the number of jobs running" and "the number of jobs running *on a core*".

> If you use -lN -j, make can kick off enough jobs to kill your system before the load average can change enough to throttle it.

Understood.

> I'm not sure I understand the comment.

This section says "GNU make will now use pthread_spawn() on systems where it is available ... It will select ...", thus "it" refers to GNU make. But GNU make will not do this at runtime (IIUC), the config system will do so at compile time. I think this could be clarified.

In all of these the main point is for the release text to be as clear as possible; it's not about explaining it to me. As long as you're satisfied it's clear I'm happy to let it go.

On Mon, Aug 26, 2019 at 11:08 AM Paul Smith <[hidden email]> wrote:
On Mon, 2019-08-26 at 10:26 -0700, David Boyce wrote:
> > the -l/--load-average option will use the contents of that file to
> determine how many jobs are running at any given instant, and compare
> that value to the load value requested.
>
> Compare and do what? This doesn't make sense to me.

I guess this is confusing.  It means, if there are N processes
currently executing on a core (not waiting) then only start a new job
if -l is >= N (equal to because one active process is make itself so we
don't count it).

> > This allows usage such as "-j -lN" for N-processor systems without
> fear of overload.
>
> There's never a fear of overload when explicitly specifying -lN for
> an N-processor system, is there?

If you use -lN -j, make can kick off enough jobs to kill your system
before the load average can change enough to throttle it.  The most
specific value we can get from getloadavg() is an average over the last
minute.  Admittedly there are other heuristics we try to use to make it
more accurate than that.

> > It will select POSIX_SPAWN_USEVFORK where that is available....
>
> Does this mean that the autotools config system will select
> POSIX_SPAWN_USEVFORK? That's not a behavior of GNU make per se.

Yes, autoconf will detect and use it.  I'm not sure I understand the
comment.


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 release candidate available

Paul Smith-20
On Mon, 2019-08-26 at 11:57 -0700, David Boyce wrote:
> > I guess this is confusing ...
>
> There may be confusion in the text between "the number of jobs
> running" and "the number of jobs running *on a core*".

Well, there can only ever be one job running on core (at a time), by
definition; I don't see the difference between those two statements?

Thanks, though!  I'll re-examine the text with a more critical eye.


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 release candidate available

Paul Smith-20
On Mon, 2019-08-26 at 15:31 -0400, Paul Smith wrote:
> On Mon, 2019-08-26 at 11:57 -0700, David Boyce wrote:
> > > I guess this is confusing ...
> >
> > There may be confusion in the text between "the number of jobs
> > running" and "the number of jobs running *on a core*".
>
> Well, there can only ever be one job running on core (at a time), by
> definition; I don't see the difference between those two statements?

Oh I think I see.  By "running" you mean, the "process is started on
the system" not "some CPU is executing the program right now".  Hah,
funny how a preconception can lead to the inability to explain things.

I'll make this more clear.

Cheers!


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: Requiring Automake 1.16.1 due to Gnulib getloadavg?

Paul Eggert
In reply to this post by Paul Smith-20
Paul Smith wrote:

> It appears that the target that's failing for me, that you didn't try
> in your test, is "make distclean".

Thanks, that explains it. Yes, "make distclean" fails for me too. I don't see a
trivial fix so I guess I'll let this sleeping dog lie too. Sorry about the noise.

> As far as I'm aware, GNU make already uses a non-recursive
> configuration of autoconf/automake at least for its own code... that
> is, there's only one Makefile.am at the root.
>
> The lib/Makefile.am is created by gnulib.  I'm not sure how to handle
> that non-recursively (if it's possible).

Coreutils does that via the Gnulib module non-recursive-gnulib-prefix-hack. The
coreutils top-level Makefile.am has "include $(top_srcdir)/lib/local.mk" and its
lib/local.mk includes the file lib/gnulib.mk that is generated by ./bootstrap.

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

GNU make 4.2.90 rc passes testsuite no where except Linux x86_64 thus far

Dennis Clarke
In reply to this post by Paul Smith-20
On 8/26/19 9:00 AM, Paul Smith wrote:

>      --------------------------------------------------------------------
>      GNU make is a tool which controls the generation of executables and
>      other non-source files of a program from the program's source files.
>
>      You can learn more at: https://www.gnu.org/software/make/
>      --------------------------------------------------------------------
>
> A new release candidate for GNU make 4.3 is available now for download:
>
>      36083ab822b50a9ecbf5467cdadff55c  make-4.2.90.tar.bz2
>      e2c9abdeaf3725f8654a5e9d7a121fa9  make-4.2.90.tar.gz
>
> You can obtain a copy from:  https://alpha.gnu.org/gnu/make/
>
> - NEWS ----------------------------------------------------------------
>
> Version 4.2.90 (26 Aug 2019)
>
> A complete list of bugs fixed in this version is available here:
>

Testing on a few system and seems to fail the testsuite in various ways
on multiple systems. Does not compile on FreeBSD 12.0-RELEASE-p10 amd64
with LLVM/Clang thus :

vesta$ $CC --version
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on
LLVM 6.0.1)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
vesta$

vesta$ echo $CFLAGS
-m64 -std=c99 -O0 -g -Werror -no-integrated-as -fno-fast-math
-fno-builtin -fdiagnostics-format=vi -fno-color-diagnostics
vesta$

Saw this :



/usr/bin/cc -DHAVE_CONFIG_H -I. -I../src   -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -m64 -std=c99 -O0 -g
-Werror -no-integrated-as -fno-fast-math -fno-builtin
-fdiagnostics-format=vi -fno-color-diagnostics -MT glob.o -MD -MP -MF
.deps/glob.Tpo -c -o glob.o glob.c
glob.c +823:27: error: incompatible pointer types passing 'char **' to
parameter of type 'char *'; dereference with *
[-Werror,-Wincompatible-pointer-types]
             = (char **) realloc (pglob->gl_pathv,
                                  ^~~~~~~~~~~~~~~
                                  *
glob.c +942:24: error: incompatible pointer types passing 'char **' to
parameter of type 'char *'; dereference with *
[-Werror,-Wincompatible-pointer-types]
                 = (char **) realloc (pglob->gl_pathv,
                                      ^~~~~~~~~~~~~~~
                                      *
glob.c +997:39: error: incompatible pointer types passing 'char **' to
parameter of type 'char *'; dereference with *
[-Werror,-Wincompatible-pointer-types]
               new_pathv = (char **) realloc (pglob->gl_pathv,
                                              ^~~~~~~~~~~~~~~
                                              *
glob.c +1388:23: error: incompatible pointer types passing 'char **' to
parameter of type 'char *'; dereference with *
[-Werror,-Wincompatible-pointer-types]
         = (char **) realloc (pglob->gl_pathv,
                              ^~~~~~~~~~~~~~~
                              *
4 errors generated.
gmake[3]: *** [Makefile:888: glob.o] Error 1
gmake[3]: Leaving directory
'/opt/bw/build/make-4.2.90_FreeBSD_12.0-p10_amd64.001/lib'
gmake[2]: *** [Makefile:908: all-recursive] Error 1
gmake[2]: Leaving directory
'/opt/bw/build/make-4.2.90_FreeBSD_12.0-p10_amd64.001/lib'
gmake[1]: *** [Makefile:814: all] Error 2
gmake[1]: Leaving directory
'/opt/bw/build/make-4.2.90_FreeBSD_12.0-p10_amd64.001/lib'
gmake: *** [Makefile:1293: all-recursive] Error 1
vesta$

So that should be just a mismatch on the types.
I have already patched that here locally.


Also :


/usr/bin/cc -DHAVE_CONFIG_H   -Isrc -I./src -Ilib -I./lib
-DLIBDIR=\"/opt/bw/lib\" -DINCLUDEDIR=\"/opt/bw/include\"
-DLOCALEDIR=\"/opt/bw/share/locale\"  -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -m64 -std=c99 -O0 -g
-Werror -no-integrated-as -fno-fast-math -fno-builtin
-fdiagnostics-format=vi -fno-color-diagnostics -MT src/getopt.o -MD -MP
-MF $depbase.Tpo -c -o src/getopt.o src/getopt.c &&\
mv -f $depbase.Tpo $depbase.Po
src/getopt.c +685:6: error: add explicit braces to avoid dangling else
[-Werror,-Wdangling-else]
                    else
                    ^
1 error generated.
gmake[1]: *** [Makefile:1207: src/getopt.o] Error 1
gmake[1]: Leaving directory
'/opt/bw/build/make-4.2.90_FreeBSD_12.0-p10_amd64.001'
gmake: *** [Makefile:1293: all-recursive] Error 1

That seems a bit pedantic.

I am walking through the function _getopt_internal and doing some code
cleanup.

I also have 32-bit Debian on arm and FreeBSD on ppc64 and Solaris on
Fujitsu SPARC and other systems.  They all fail the testsuite in various
ways.  For now.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 rc passes testsuite no where except Linux x86_64 thus far

Paul Smith-20
On Mon, 2019-08-26 at 16:19 -0400, Dennis Clarke wrote:
> Testing on a few system and seems to fail the testsuite in various
> ways on multiple systems. Does not compile on FreeBSD 12.0-RELEASE-
> p10 amd64 with LLVM/Clang thus :

Thanks Dennis.

Please note that glob/fnmatch/getopt are not technically supported by
GNU make, so I don't apply patches for them to fix warnings unless they
are actual errors in the code.  Ditto for general code cleanup to these
files.

I recommend you don't compile with -Werror.

If you find warnings to other files in src/ I'm interested in that.

To fix this we'd need to start using the current gnulib versions of
these files instead of the old ones we have now, and then if there are
broken things they can get fixed there.

As an example, when I run the regression tests on MacOS one of them
fails in the symlink tests because (I believe) it's using the older
glob.c/fnmatch.c we provide.  On GNU/Linux we use the versions that are
provided with the system libc (because it's glibc).

The reason this is difficult is because I'm not sure that the gnulib
versions of glob/fnmatch work well with Windows (and VMS?)... or if
they do what the best way to integrate them with gnu make is.  I'll
look into it.


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 rc passes testsuite no where except Linux x86_64 thus far

Dennis Clarke
On 8/26/19 4:32 PM, Paul Smith wrote:

> On Mon, 2019-08-26 at 16:19 -0400, Dennis Clarke wrote:
>> Testing on a few system and seems to fail the testsuite in various
>> ways on multiple systems. Does not compile on FreeBSD 12.0-RELEASE-
>> p10 amd64 with LLVM/Clang thus :
>
> Thanks Dennis.
>
> Please note that glob/fnmatch/getopt are not technically supported by
> GNU make, so I don't apply patches for them to fix warnings unless they
> are actual errors in the code.  Ditto for general code cleanup to these
> files.
>

Sadly I just wrote a 600 line patch. Fixes the issues and the warnings
and the point type mismatch.

> I recommend you don't compile with -Werror.

I tend to be a bit pedantic on a release candidate just to shake out the
code.

>
> If you find warnings to other files in src/ I'm interested in that.
>
> To fix this we'd need to start using the current gnulib versions of
> these files instead of the old ones we have now, and then if there are
> broken things they can get fixed there.

    * nod *

> As an example, when I run the regression tests on MacOS one of them
> fails in the symlink tests because (I believe) it's using the older
> glob.c/fnmatch.c we provide.  On GNU/Linux we use the versions that are
> provided with the system libc (because it's glibc).
>
> The reason this is difficult is because I'm not sure that the gnulib
> versions of glob/fnmatch work well with Windows (and VMS?)... or if
> they do what the best way to integrate them with gnu make is.  I'll
> look into it.
>

Well I am getting consistent results here on a number of systems across
various OS and platform architectures.  A few of them fail in the test
functions/wildcard and I see :

vesta$
vesta$ uname -apKU
FreeBSD vesta 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC  amd64
amd64 1200086 1200086
vesta$ cc --version
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on
LLVM 6.0.1)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
vesta$ find . | grep 'diff'
./tests/work/functions/wildcard.diff.7
vesta$ cat ./tests/work/functions/wildcard.diff.7
*** work/functions/wildcard.base.7      Mon Aug 26 21:30:53 2019
--- work/functions/wildcard.log.7       Mon Aug 26 21:30:53 2019
***************
*** 1 ****
! __ldir
--- 1 ----
!
vesta$

OKay over on ppc64 FreeBSD 13-CURRENT I see the exact same result while
using gcc 8.2.0 there.

Debian Linux "sid" on i686 with gcc 9.2.0 throws a ton of failures :

esther$
esther$ uname -a
Linux esther 5.2.0-2-686 #1 SMP Debian 5.2.9-2 (2019-08-21) i686 GNU/Linux
esther$ gcc --version
gcc (Debian 9.2.1-4) 9.2.1 20190821
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

esther$

esther$ find . | grep 'diff'
./tests/work/targets/SECONDARY.diff.3
./tests/work/targets/INTERMEDIATE.diff.2
./tests/work/targets/INTERMEDIATE.diff.5
./tests/work/targets/SECONDARY.diff.2
./tests/work/features/archives.diff.1
./tests/work/features/archives.diff.4
./tests/work/features/reinvoke.diff.1
./tests/work/features/archives.diff.2
./tests/work/features/archives.diff.6
./tests/work/features/output-sync.diff.12
./tests/work/features/output-sync.diff.11
./tests/work/features/archives.diff.3
./tests/work/features/reinvoke.diff.3
./tests/work/features/reinvoke.diff
./tests/work/features/archives.diff.5
./tests/work/features/vpathplus.diff.3
./tests/work/features/reinvoke.diff.2
./tests/work/features/load.diff.3
./tests/work/options/symlinks.diff.1
./tests/work/options/symlinks.diff.6
esther$


I don't even know where to begin on that machine.

Debian 9.9 on 32-bit arm7 fails the wildcard test with identical
results to the FreeBSD systems :

arm7$ uname -a
Linux arm7 4.4.132+ #1 SMP Wed May 15 19:37:54 CST 2019 armv7l GNU/Linux
arm7$ cat /etc/debian_version
9.9
arm7$ gcc --version
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

arm7$
arm7$ cat ./tests/work/functions/wildcard.diff.7
*** work/functions/wildcard.base.7      Mon Aug 26 19:14:47 2019
--- work/functions/wildcard.log.7       Mon Aug 26 19:14:47 2019
***************
*** 1 ****
! __ldir
--- 1 ----
!
arm7$


The Solaris 10 SPARC machine blows up in so many places I don't even
know where to begin. It compiles clean. Perfect with Oracle Studio c99
and with strict CFLAGS but the testsuite fails in a spectacular fashion:

beta$ find . | grep 'diff'
./tests/work/features/errors.diff.4
./tests/work/features/errors.diff.3
./tests/work/features/vpathplus.diff.2
./tests/work/features/archives.diff.10
./tests/work/features/load.diff.3
./tests/work/features/output-sync.diff.14
./tests/work/features/errors.diff.5
./tests/work/features/load.diff.4
./tests/work/features/grouped_targets.diff
./tests/work/features/errors.diff.6
./tests/work/functions/shell.diff.6
./tests/work/functions/shell.diff.5
./tests/work/functions/shell.diff.7
./tests/work/functions/wildcard.diff.7
beta$

------------------------------------------------------------------------------
              Running tests for GNU make on SunOS beta 5.10 sun4u
                                GNU Make 4.2.90
------------------------------------------------------------------------------

Finding tests...

.
.
.

features/archives ....................................... FAILED (11/12
passed)
features/errors ......................................... FAILED (3/7
passed)
features/grouped_targets ................................ FAILED (11/12
passed)
features/load ........................................... FAILED (3/5
passed)
features/output-sync .................................... FAILED (14/15
passed)
features/vpathplus ...................................... FAILED (3/4
passed)
functions/shell ......................................... FAILED (5/8
passed)
functions/wildcard ...................................... FAILED (7/8
passed)


So not sure where to begin here.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders NOT optional


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 rc passes testsuite no where except Linux x86_64 thus far

Paul Smith-20
On Mon, 2019-08-26 at 17:42 -0400, Dennis Clarke wrote:
> Well I am getting consistent results here on a number of systems
> across various OS and platform architectures.  A few of them fail in
> the test functions/wildcard and I see :

This one (the __ldir test) is exactly the one I was referring to as
failing on MacOS: it's a bug in handling symlinks in the older
glob.c/fnmatch.c implementation we have.  This bug has been fixed in
GNU libc (and the later gnulib implementations).

This doesn't fail on GNU/Linux systems, if they choose the system GNU
libc (and it has this bug fixed--older systems may not).

> Debian Linux "sid" on i686 with gcc 9.2.0 throws a ton of failures :

I'd be interested to see the diffs generated on these other systems.
If convenient, please tar them up and send them to me directly (no need
to send them to the list).

Cheers!


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 rc passes testsuite no where except Linux x86_64 thus far

Dennis Clarke
On 8/26/19 5:51 PM, Paul Smith wrote:

> On Mon, 2019-08-26 at 17:42 -0400, Dennis Clarke wrote:
>> Well I am getting consistent results here on a number of systems
>> across various OS and platform architectures.  A few of them fail in
>> the test functions/wildcard and I see :
>
> This one (the __ldir test) is exactly the one I was referring to as
> failing on MacOS: it's a bug in handling symlinks in the older
> glob.c/fnmatch.c implementation we have.  This bug has been fixed in
> GNU libc (and the later gnulib implementations).
>
> This doesn't fail on GNU/Linux systems, if they choose the system GNU
> libc (and it has this bug fixed--older systems may not).
>

It does fail everywhere with the exception of a single Debian Linux
x86_64 system.  On 32-bit Debian systems there are many many failures
on both arm and i686.


> I'd be interested to see the diffs generated on these other systems.
> If convenient, please tar them up and send them to me directly (no need
> to send them to the list).
>

Alrighty then I will tarball up stuff wherein there is information in
each tarball about the environment, the compiler and then the testsuite
results. Hope we can get a clean release that runs everywhere or at
least nearly everywhere.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional





_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 release candidate available

Dennis Clarke
In reply to this post by Paul Smith-20
On 8/26/19 9:00 AM, Paul Smith wrote:

>      --------------------------------------------------------------------
>      GNU make is a tool which controls the generation of executables and
>      other non-source files of a program from the program's source files.
>
>      You can learn more at: https://www.gnu.org/software/make/
>      --------------------------------------------------------------------
>
> A new release candidate for GNU make 4.3 is available now for download:
>
>      36083ab822b50a9ecbf5467cdadff55c  make-4.2.90.tar.bz2
>      e2c9abdeaf3725f8654a5e9d7a121fa9  make-4.2.90.tar.gz
>
> You can obtain a copy from:  https://alpha.gnu.org/gnu/make/
>
> - NEWS ----------------------------------------------------------------

I'll dig into this but on RHEL 7.4 x86_64 we see :

src/job.c: In function 'reap_children':
src/job.c:754:17: error: incompatible type for argument 1 of 'wait'
                  EINTRLOOP (pid, wait (&status));
                  ^
In file included from src/job.c:126:0:
/usr/include/sys/wait.h:114:16: note: expected '__WAIT_STATUS' but
argument is of type 'int *'
  extern __pid_t wait (__WAIT_STATUS __stat_loc);
                 ^
gmake[1]: *** [Makefile:1207: src/job.o] Error 1
gmake[1]: Leaving directory
'/opt/bw/build/make-4.2.90_rhel_74_3.10.0-693.el7.x86_64.001'
gmake: *** [Makefile:1293: all-recursive] Error 1

I have seen that on no other system thus far today.
So that is a bit odd.

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 release candidate available

Paul Smith-20
On Mon, 2019-08-26 at 19:33 -0400, Dennis Clarke wrote:
> I'll dig into this but on RHEL 7.4 x86_64 we see :
>
> src/job.c: In function 'reap_children':
> src/job.c:754:17: error: incompatible type for argument 1 of 'wait'
>                   EINTRLOOP (pid, wait (&status));

That is REALLY disturbing, because it means that configure couldn't
detect either waitpid() or wait3(), both of which have been available
since approximately forever.  Something went badly wrong with the
configure run on this system.

Thanks for sending me links to the other stuff.  I haven't looked at
them all yet but there seems to be a combination of two things:

First the glob.c/wildcard error.  Note that this is not a new error:
it's always been like this.  What's new  is (a) the test which shows
the problem, and (b) that it _doesn't_ fail on some sufficiently new
systems.  It's not clear this can be fixed, at least for GNU libc-based
systems of a certain vintage.  In any even it's probably a bug that
needs to be file with the system.

The second group appears to be for systems that handle posix_spawn()
errors differently.  If you check the POSIX spec you'll see that error
handling for posix_spawn() is very tricky.  Some systems will fail
posix_spawn() if the program to be invoked doesn't exist (this is how
GNU/Linux and MacOS work).  Other programs will have posix_spawn()
succeed, but then fail the process later.  I think this latter behavior
is what you're seeing on the systems where you get a lot of errors.
The diffs I've seen so far are about missing "no such file" messages.

I thought about trying to handle this but (1) it's a bit annoying and
(2) I didn't know if there were any systems that used this latter
behavior.  Looks like there might be.


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 release candidate available

Dennis Clarke
On 8/26/19 10:59 PM, Paul Smith wrote:

> On Mon, 2019-08-26 at 19:33 -0400, Dennis Clarke wrote:
>> I'll dig into this but on RHEL 7.4 x86_64 we see :
>>
>> src/job.c: In function 'reap_children':
>> src/job.c:754:17: error: incompatible type for argument 1 of 'wait'
>>                    EINTRLOOP (pid, wait (&status));
>
> That is REALLY disturbing, because it means that configure couldn't
> detect either waitpid() or wait3(), both of which have been available
> since approximately forever.  Something went badly wrong with the
> configure run on this system.

I know and it was a show stopper for me.  I just had to stop and stare
at my coffee cup after trying this across a bunch of machines.

The entire configure log is there in the tarball and I may stare at it
tomorrow.

> Thanks for sending me links to the other stuff.  I haven't looked at
> them all yet but there seems to be a combination of two things:
>
> First the glob.c/wildcard error.


Yeah .. that one.   :-\

> Note that this is not a new error:
> it's always been like this.  What's new  is (a) the test which shows
> the problem, and (b) that it _doesn't_ fail on some sufficiently new
> systems.

Right !!   I did this and had others watching and we were all wondering
why Debian stable was happy and Debian sid had a fit. Of course there
was also the x86_64 versus i686 architecture there too.


>  It's not clear this can be fixed, at least for GNU libc-based
> systems of a certain vintage.  In any even it's probably a bug that
> needs to be file with the system.

Everything I have is very very recent.

> The second group appears to be for systems that handle posix_spawn()
> errors differently.  If you check the POSIX spec you'll see that error
> handling for posix_spawn() is very tricky.  

POSIX .. I have heard of that :)

> Some systems will fail
> posix_spawn() if the program to be invoked doesn't exist (this is how
> GNU/Linux and MacOS work).  Other programs will have posix_spawn()
> succeed, but then fail the process later.  I think this latter behavior
> is what you're seeing on the systems where you get a lot of errors.
> The diffs I've seen so far are about missing "no such file" messages.
>
> I thought about trying to handle this but (1) it's a bit annoying and
> (2) I didn't know if there were any systems that used this latter
> behavior.  Looks like there might be.
>

Sounds like whiskey in my coffee cup tomorrow to look at this all again.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.90 release candidate available

Andreas Schwab
In reply to this post by Paul Smith-20
On Aug 26 2019, Paul Smith <[hidden email]> wrote:

> On Mon, 2019-08-26 at 10:26 -0700, David Boyce wrote:
>> Does this mean that the autotools config system will select
>> POSIX_SPAWN_USEVFORK? That's not a behavior of GNU make per se.
>
> Yes, autoconf will detect and use it.  I'm not sure I understand the
> comment.

I think that item should be moved to the developer news.

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
1234