[bug #62174] fix test functions/shell on aix.

[Dmitry Goncharov]

Follow-up Comment #3, bug #62174 (project make):

i guess this fell through the cracks. Paul, can you please have a look at
sv62174_fix2.diff?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63185] configure fails to detect getloadavg declaration on sun and aix.

[Dmitry Goncharov]

Follow-up Comment #5, bug #63185 (project make):

i guess this fell through the cracks. Paul, can you please have a look at the
attached patch?
One part of the patch you already applied, but there is the second part, which
is still needed.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63260] Avoid infinite recursion.

[Dmitry Goncharov]

Follow-up Comment #5, bug #63260 (project make):

Thanks, Paul. This indeed fixes the infinite recursion on reiserfs.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: GNU make 4.3.92 on mingw

[Paul Smith]

On Tue, 2022-10-25 at 22:13 +0300, Eli Zaretskii wrote:
> > So if we see a difference it must be that there's some OTHER
> > difference not just CRLF.  Or, the test suite comparison has a
> > bug.  I'll have to look more closely at the output.
> 
> I do see differences unrelated to CRLF, see below.

Yes, I failed to explain well.  The framework will do the comparison of
base with log using "modified" versions that strip CRLF etc.

Only IF that comparison of modified versions fails (there's some
difference) will diff(1) be run.  When diff(1) is run, it's run on the
ORIGINAL versions not the modified versions.

So, you won't see an error if the ONLY difference is CRLF.  But if
there's some OTHER difference in addition to CRLF then you'll see both
that other difference AND the CRLF difference.


Anyway, I've discovered the basis of (most of?) the differences thanks
to the results files in the error file.

When Bruno builds for MinGW he builds inside of the Cygwin context,
using a MinGW "cross-compiler".  So he runs ./configure etc. in Cygwin
but with CC=x86_64-w64-mingw32-gcc installed in Cygwin.

Then to run the tests, he again runs it from the Cygwin shell, using
the Cygwin version of Perl.  We can see that from the test log:

Running tests for GNU Make on cygwin
  ^^

This value is obtained from Perl's $^O variable containing the "host"
OS.  Many of the tests use this value or values derived from it to
decide whether to run tests in a "Windows context" or in a "POSIX
context".  When we run tests in a POSIX context we assume we have all
the POSIX stuff including POSIX fork/exec, paths, etc. not the MinGW
CreateProcess, Windows paths, etc.  "cygwin" is assumed to be a POSIX
context.

The test suite just doesn't handle this kind of "cross-built"
environment right now, where Perl has a different target than GNU make.
Probably we should be determining the value of $(MAKE_HOST) to decide
how to run the tests, rather than the value of Perl's $^O variable. 
But, maybe in some places we'd need both.

Re: GNU make 4.3.92 on mingw

[Eli Zaretskii]

> From: Paul Smith 
> Cc: br...@clisp.org, bug-make@gnu.org
> Date: Tue, 25 Oct 2022 14:10:25 -0400
> 
> On Tue, 2022-10-25 at 19:37 +0300, Eli Zaretskii wrote:
> > > A lot of these seem to be CRLF errors in the diff, where it would
> > > otherwise match.  I know that the test framework does some
> > > manipulation of CRLF.
> > 
> > If the test suite runs Diff, it should invoke it with the
> > "--strip-trailing-cr" switch, I think.  Because Cygwin's (and MSYS's)
> > Diff doesn't use Windows text-mode I/O.
> 
> OK I looked into the test suite to remind myself what it does.
> 
> First it compares the base and the log file directly; if they are equal
> we're done.  If they're not equal we manipulate them by (a) converting
> backslash to slash and (b) converting CRLF to LF, then we compare them
> again.  If they're now the same, declare victory.  If they're still
> different, then we invoke diff on the original versions.
> 
> So if we see a difference it must be that there's some OTHER difference
> not just CRLF.  Or, the test suite comparison has a bug.  I'll have to
> look more closely at the output.

I do see differences unrelated to CRLF, see below.

> I don't want to just add that diff switch because it's a GNU diff
> switch and won't work on systems without GNU diff (BSD, etc.)  If I
> wanted to use it I'd need to first check that it was available.  Which
> could be done of course.

MinGW uses only GNU Diff.

Here are the differences I see in the files posted by Bruno.  They
seem to show problems unrelated to EOL format:

> *** work/features/archives.base.1 Tue Oct 25 03:35:39 2022
> --- work/features/archives.log.1  Tue Oct 25 03:35:39 2022
> ***
> *** 1,2 
> ! x86_64-w64-mingw32-ar -rvU libxx.a a2.o
>   a - a2.o
> --- 1,4 
> ! x86_64-w64-mingw32-ar -rvU libxx.a a1.o

> ! r - a1.o
> ! x86_64-w64-mingw32-ar -rvU libxx.a a2.o

>   a - a2.o

This (and other similar diffs in features/archives) seem to indicate
that x86_64-w64-mingw32-ar behaves unexpectedly?

> *** work/features/errors.base.3   Tue Oct 25 03:35:51 2022
> --- work/features/errors.log.3Tue Oct 25 03:35:51 2022
> ***
> *** 1,3 
> ! ./foobarbazbozblat xx yy
> ! make: ./foobarbazbozblat: No such file or directory
> ! make: [work/features/errors.mk.2:2: one] Error 127 (ignored)
> --- 1,4 
> ! ./foobarbazbozblat xx yy

> ! process_begin: CreateProcess(NULL, ./foobarbazbozblat xx yy, ...) failed.

> ! make (e=2): The system cannot find the file specified.


> ! make: [work/features/errors.mk.2:2: one] Error 2 (ignored)


This is a real issue; I patch this (and other) tests to expect the
error messages produced by Make on Windows.

> *** work/features/include.base.36 Tue Oct 25 03:36:06 2022
> --- work/features/include.log.36  Tue Oct 25 03:36:06 2022
> ***
> *** 5,8 
>   GNUmakefile
>   makefile
>   Makefile
> ! make: 'all' is up to date.
> --- 5,9 
>   GNUmakefile
>   makefile
>   Makefile
> ! makefile.mak
> ! make: 'all' is up to date.


This seems to be because Bruno's port of Make is not recognized as
"W32", because features/include does expect makefile.mak then:

  if ($port_type eq 'W32') {
  $defaults = "GNUmakefile\nmakefile\nMakefile\nmakefile.mak";
  } else {
  $defaults = "GNUmakefile\nmakefile\nMakefile";
  }

> *** work/features/jobserver.base.5Tue Oct 25 03:36:07 2022
> --- work/features/jobserver.log.5 Tue Oct 25 03:36:07 2022
> ***
> *** 1,2 
> ! make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> rule.
> ! make[1]: Nothing to be done for 'foo'.
> --- 1 
> ! make: *** Unknown jobserver auth style 'pipe'.  Stop.


Same here: this test was not supposed to be run for the "W32" port.

> *** work/features/jobserver.base.6Tue Oct 25 03:36:08 2022
> --- work/features/jobserver.log.6 Tue Oct 25 03:36:08 2022
> ***
> *** 1,6 
> ! make: Entering directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> ! make[1]: Entering directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> ! make[1]: warning: -j1 forced in submake: resetting jobserver mode.
>   hi
> ! make[1]: Leaving directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> ! make: Leaving directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> --- 1,6 
> ! make: Entering directory 
> 'C:/cygwin64/home/bruno/make-4.3.92/build-mingw64/tests'

> ! make[1]: Entering directory 
> 'C:/cygwin64/home/bruno/make-4.3.92/build-mingw64/tests'

> ! make[1]: warning: -j1 forced in submake: resetting jobserver mode.

>   hi
> ! make[1]: Leaving directory 
> 'C:/cygwin64/home/bruno/make-4.3.92/build-mingw64/tests'

> ! make: Leaving directory 
> 'C:/cygwin64/home/bruno/make-4.3.92/build-mingw64/tests'


This seems to be due to inconsistencies in file naming between Make
and some other program (Perl? Bash?).  Similar failures are seen in
some other failed tests.

> *** work/features/output-sync.base.11 Tue Oct 25 03:36:25 2

Re: GNU make 4.3.92 on mingw

[David Boyce]

I'd think it would be easy to write a diff script in Perl to avoid platform
dependencies. In fact the result would be simpler than Paul describes
because instead of actually modifying logfiles the mods could be done
in-memory by the script. Reading in two text files, strinpping off
newlines, optionally changing \ to /, and comparing is pretty trivial.

On Tue, Oct 25, 2022 at 2:12 PM Paul Smith  wrote:

> On Tue, 2022-10-25 at 19:37 +0300, Eli Zaretskii wrote:
> > > A lot of these seem to be CRLF errors in the diff, where it would
> > > otherwise match.  I know that the test framework does some
> > > manipulation of CRLF.
> >
> > If the test suite runs Diff, it should invoke it with the
> > "--strip-trailing-cr" switch, I think.  Because Cygwin's (and MSYS's)
> > Diff doesn't use Windows text-mode I/O.
>
> OK I looked into the test suite to remind myself what it does.
>
> First it compares the base and the log file directly; if they are equal
> we're done.  If they're not equal we manipulate them by (a) converting
> backslash to slash and (b) converting CRLF to LF, then we compare them
> again.  If they're now the same, declare victory.  If they're still
> different, then we invoke diff on the original versions.
>
> So if we see a difference it must be that there's some OTHER difference
> not just CRLF.  Or, the test suite comparison has a bug.  I'll have to
> look more closely at the output.
>
> I don't want to just add that diff switch because it's a GNU diff
> switch and won't work on systems without GNU diff (BSD, etc.)  If I
> wanted to use it I'd need to first check that it was available.  Which
> could be done of course.
>
>

Re: GNU make 4.3.92 on mingw

[Paul Smith]

On Tue, 2022-10-25 at 19:37 +0300, Eli Zaretskii wrote:
> > A lot of these seem to be CRLF errors in the diff, where it would
> > otherwise match.  I know that the test framework does some
> > manipulation of CRLF.
> 
> If the test suite runs Diff, it should invoke it with the
> "--strip-trailing-cr" switch, I think.  Because Cygwin's (and MSYS's)
> Diff doesn't use Windows text-mode I/O.

OK I looked into the test suite to remind myself what it does.

First it compares the base and the log file directly; if they are equal
we're done.  If they're not equal we manipulate them by (a) converting
backslash to slash and (b) converting CRLF to LF, then we compare them
again.  If they're now the same, declare victory.  If they're still
different, then we invoke diff on the original versions.

So if we see a difference it must be that there's some OTHER difference
not just CRLF.  Or, the test suite comparison has a bug.  I'll have to
look more closely at the output.

I don't want to just add that diff switch because it's a GNU diff
switch and won't work on systems without GNU diff (BSD, etc.)  If I
wanted to use it I'd need to first check that it was available.  Which
could be done of course.

Re: GNU make 4.3.92 on mingw

[Eli Zaretskii]

> From: Paul Smith 
> Date: Tue, 25 Oct 2022 12:07:08 -0400
> 
> On Tue, 2022-10-25 at 16:29 +0200, Bruno Haible wrote:
> > With GNU make 4.3.92, this is down to 75 test failures.
> 
> Just curious how this MinGW test works; are you running the MinGW
> "cross-compiler" installed by the Cygwin package manager, and doing the
> build/test from within a Cygwin shell?
> 
> A lot of these seem to be CRLF errors in the diff, where it would
> otherwise match.  I know that the test framework does some manipulation
> of CRLF.  Maybe it only strips CRLF when it thinks we're running in a
> "Windows" environment, and for some reason this environment is not
> detected properly.

If the test suite runs Diff, it should invoke it with the
"--strip-trailing-cr" switch, I think.  Because Cygwin's (and MSYS's)
Diff doesn't use Windows text-mode I/O.

The tests succeed here, because I made 'diff' a shell script that runs
the "real" Diff with --strip-trailing-cr.  I found long ago that many
test suites have this problem, so I fixed it once and for all.

Re: GNU Make 4.3.92 release candidate available

[Eli Zaretskii]

> From: Paul Smith 
> Date: Mon, 24 Oct 2022 02:59:18 -0400
> 
> I expect this to be the final release candidate before GNU Make 4.4.
> I will probably allow for testing for about a week.
> 
> 
> 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.4 is available now for download:
> 
>   724e9144fa841bb1315aee1f2fd8e1d2  make-4.3.92.tar.lz
>   09a2bb194655c99cd9eff23a9128df7f  make-4.3.92.tar.gz
> 
> You can obtain a copy from:  https://alpha.gnu.org/gnu/make/

The MinGW port of this builds cleanly and passes the test suite (after
my usual patching of it).

Re: GNU make 4.3.92 on mingw

[Paul Smith]

On Tue, 2022-10-25 at 16:29 +0200, Bruno Haible wrote:
> With GNU make 4.3.92, this is down to 75 test failures.

Just curious how this MinGW test works; are you running the MinGW
"cross-compiler" installed by the Cygwin package manager, and doing the
build/test from within a Cygwin shell?

A lot of these seem to be CRLF errors in the diff, where it would
otherwise match.  I know that the test framework does some manipulation
of CRLF.  Maybe it only strips CRLF when it thinks we're running in a
"Windows" environment, and for some reason this environment is not
detected properly.

There are other similar issues, like the test thinks we can use the
pipe version of the jobserver when that's not supported in MinGW.

I'll take a look at this.

Re: GNU Make 4.3.92 on OpenBSD 6.5

[Paul Smith]

On Tue, 2022-10-25 at 16:32 +0200, Bruno Haible wrote:
> On OpenBSD 6.5, I see 6 test failures.

There are SIGSEGV in the loadapi tests; I'm not sure where to go with
this as I'll need some debugging done on the segv at least a backtrace
or something.

And, there are timeout errors.

If you change this line in tests/test_driver.pl:

  $test_timeout = 5;

to something like:

  $test_timeout = 30;

do you still see failures like these:

  Test timed out after 5 seconds
  Error running /.../make (expected 15; got 14) ...

  Caught signal 14!

Re: GNU make 4.3.92 on Cygwin

[Paul Smith]

On Tue, 2022-10-25 at 16:27 +0200, Bruno Haible wrote:
> With GNU make 4.3.92, we're down to 10 test failures.

Just to note, I was able to install Cygwin64 on one of my Windows
systems and the latest code built and ran with no failures there.

All the failures on Cygwin in your tests are of this form:

make[1]: *** Cannot open jobserver /home/bruno/make-4.3.92/build-
cygwin64/tests/_tmp/GMfifo5372: Device or resource busy.  Stop.

I checked my Cygwin build and it also sets up to use mkfifo, but I
don't see these errors.  I see that there are various discussions of
cygwin's mkfifo implementation, from 5-10 years ago anyway, saying it's
not so great and that opening it from multiple processes is problematic
(which is exactly what we want to do here).  But, it worked for me.

Maybe your system has an older version of Cygwin installed?  I just
installed the very latest.  I don't really know how to find a "version"
of Cygwin or what part of it implements the mkfifo emulation, but if
it's the "cygwin" package I have version 3.3.6-1.

Re: GNU make 4.3.92 on Manjaro 17 — bi-arch problem

[Paul Smith]

On Tue, 2022-10-25 at 16:20 +0200, Bruno Haible wrote:
> Unfortunately, it did not fix the problem. Find attached the details
> of that failed build.

Hm.  The link test I added did fail, as expected, but somehow that did
not translate to disabling Guile support.  I must have messed up
something in the configure script I'll take another look.

Re: GNU Make 4.3.92 on OpenBSD 6.5

[Bruno Haible]

On OpenBSD 6.5, I see 6 test failures.



makeerror-x86_64-unknown-openbsd6.5.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on Cygwin

[Bruno Haible]

I wrote:
> On Cygwin 2.9.0 (64-bit), compilation works fine, but there are 11 test
> failures.

With GNU make 4.3.92, we're down to 10 test failures.



makeerror-x86_64-pc-cygwin2.9.0.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on mingw

[Bruno Haible]

I wrote:
> On mingw (on Windows 10 in a Cygwin dev environment), compilation works
> fine, but there are 91 test failures.

With GNU make 4.3.92, this is down to 75 test failures.



makeerror-x86_64-w64-mingw.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on GNU/Hurd

[Bruno Haible]

Paul Smith wrote:
> On Wed, 2022-10-19 at 03:14 +0200, Bruno Haible wrote:
> > PATH_MAX does not exist on GNU/Hurd (intentionally, because file
> > names are of arbitrary length).
> 
> Thanks, I've fixed this by setting a large value (4096) as PATH_MAX if
> it's not set anywhere.

Thanks. With GNU make 4.3.92, the compilation now succeeds, but there are
9 test failures.



makeerror-i686-unknown-hurd.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on Solaris 11

[Bruno Haible]

I wrote:
> On Solaris 11.4 / x86_64, in 64-bit mode, the compilation works fine, but 
> there
> are 20 test failures. Likewise in 32-bit mode.
> 
> On Solaris 11 OmniOS, in 64-bit mode, the compilation works fine, but there
> are 22 test failures. In 32-bit mode, even 26 test failures.
> 
> On Solaris 11 OpenIndiana, in 64-bit mode, the compilation works fine, but 
> there
> are 20 test failures. In 32-bit mode, even 24 test failures.

With GNU make 4.3.92, the results are much better:
  - On Solaris 11.4 and Solaris 11 OpenIndiana, all tests pass.
  - On Solaris 11 OmniOS, there are only 3 test failures. Attached.



makeerror-x86_64-pc-solaris2.11-omnios.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on FreeBSD

[Bruno Haible]

I wrote:
> On FreeBSD 11 / x86, the compilation works fine but 1 test fails.

On the same machine, with GNU make 4.3.92, all tests pass.

Re: GNU make 4.3.92 on openSUSE Leap 15.2

[Bruno Haible]

I wrote:
> On OpenSUSE Leap 15.2 / x86_64 (a glibc 2.26 system), the compilation works 
> fine
> but 3 tests fail.

On the same system, with GNU make 4.3.92, I see only 1 test failure: the
wildcard tests. Due to the older glibc.



makeerror-x86_64-pc-linux-gnu-opensuse15.2.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on Manjaro 17 — bi-arch problem

[Bruno Haible]

Paul Smith wrote:
> > The cause:
> > libguile-2.2.so happens to be installed only as 64-bit binaries, in
> > /usr/lib.
> > Not as 32-bit binaries, in /usr/lib32. Yet, /usr/include/guile/2.2/
> > exists.
> 
> I added extra configure checking to try to link with Guile, not just
> assume that if we can find the header we're good to go.

Unfortunately, it did not fix the problem. Find attached the details
of that failed build.



makeerror-manjaro17-32bit.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on Manjaro 17

[Bruno Haible]

I wrote:
> On Manjaro Linux 17 (a glibc 2.28 system) in 64-bit mode, the compilation
> works fine, but there are 2 test failures.

With GNU make 4.3.92, all tests pass.

Re: GNU make 4.3.92 on CentOS 8 Stream

[Bruno Haible]

I wrote:
> On CentOS 8 Stream / x86_64 (a glibc 2.28 system), the compilation works fine,
> but the test suite has failures in the 'output-sync' category:
> - 3 failures in a build with gcc

The same 3 failures still occur with GNU make 4.3.92.




makeerror-x86_64-pc-linux-gnu-centos-8-stream.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on Debian 11.1

[Bruno Haible]

I wrote:
> On Debian 11.1 / x86_64 (a glibc 2.31 system) compilation succeeds
> but there are 2 test failures.

With GNU make 4.3.92, I see all tests pass.

Re: GNU make 4.3.92 on Debian 9.1

[Bruno Haible]

Martin Dorey wrote:
> I looked into it further and concluded that failure is indeed expected on 
> Debian 9, where it's a harmless documentation of the legacy $(wildcard) 
> behavior with dangling symlinks there.

GNU make 4.3.92, on the same machine, shows only this one failure:
functions/wildcard .. FAILED (9/10 passed)



makeerror-i686-pc-linux-gnu-debian9.1.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.3.92 release candidate available

[Paul Smith]

On Tue, 2022-10-25 at 08:42 +0200, Martin Reinders wrote:
> but from what Paul said in https://lists.gnu.org/archive/html/bug-
> make/2019-05/msg00017.html
> 
> > Argh, another glob.c issue.  I really need to figure out how to
> > update to a newer version, preferably without breaking Windows AND
> > pulling in 75% of gnulib stuff in the process.
> 
> I assume we still have to live with these warnings?

Yes, I have no plans to try to resolve this before 4.4.  I've been
noodling it over in the back of my brain but so far no epiphanies.

> Apart from that, there is only one compiler warning:
> 
>   src/getopt.c:685:6: warning: add explicit braces to avoid dangling
> else [-Wdangling-else]
>    else
>    ^
> 
> A fix had been posted in
> https://savannah.gnu.org/bugs/?func=detailitem&item_id=58075. That
> looks like a "small effort" change to me, perhaps it can be
> incorporated into GNU Make 4.4?

The thing is that getopt.c is also an external file, like glob.c.  It's
not developed by GNU make, it was pulled in from an external toolset
(like gnulib--but a long time ago so it's not receiving updates).

I prefer to not make changes to these types of files locally but
instead find a way to import newer versions.

In any event, the C code here is correct, regardless of the warning.

Cheers!

Re: GNU Make 4.3.92 release candidate available

[Martin Reinders]

Am 24.10.22 um 08:59 schrieb Paul Smith:
> I expect this to be the final release candidate before GNU Make 4.4.
> I will probably allow for testing for about a week.

(I had accidentally posted this yesterday as reply to an older thread, but it 
was meant as feedback to make-4.3.92.)

On macOS, compiling "glob.c" gives these warnings:

  glob.c:823:27: warning: incompatible pointer types passing 'char **' to 
parameter of type 'char *'; dereference with * [-Wincompatible-pointer-types]
= (char **) realloc (pglob->gl_pathv,
 ^~~
 *
  glob.c:942:24: warning: incompatible pointer types passing 'char **' to 
parameter of type 'char *'; dereference with * [-Wincompatible-pointer-types]
= (char **) realloc (pglob->gl_pathv,
 ^~~
 *
  glob.c:997:39: warning: incompatible pointer types passing 'char **' to 
parameter of type 'char *'; dereference with * [-Wincompatible-pointer-types]
  new_pathv = (char **) realloc (pglob->gl_pathv,
 ^~~
 *
  glob.c:1388:23: warning: incompatible pointer types passing 'char **' to 
parameter of type 'char *'; dereference with * [-Wincompatible-pointer-types]
= (char **) realloc (pglob->gl_pathv,
 ^~~
 *

but from what Paul said in 
https://lists.gnu.org/archive/html/bug-make/2019-05/msg00017.html

> Argh, another glob.c issue.  I really need to figure out how to update
> to a newer version, preferably without breaking Windows AND pulling in
> 75% of gnulib stuff in the process.

I assume we still have to live with these warnings?

Apart from that, there is only one compiler warning:

  src/getopt.c:685:6: warning: add explicit braces to avoid dangling else 
[-Wdangling-else]
   else
   ^

A fix had been posted in 
https://savannah.gnu.org/bugs/?func=detailitem&item_id=58075. That looks like a 
"small effort" change to me, perhaps it can be incorporated into GNU Make 4.4?

Regards, Martin