Re: GNU make 4.3.92 on mingw
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
> 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
Re: GNU make 4.3.92 on mingw
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
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
> 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 on mingw
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 mingw
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
