Re: [platform-testers] new snapshot available: coreutils-8.22.151-37b36

[Pádraig Brady]

On 07/14/2014 10:38 PM, Eric Blake wrote:
> On 07/13/2014 08:47 PM, Pádraig Brady wrote:
> 
> [umm - was the Reply-to of address@hidden intentional?
> I'm assuming you wanted replies just to the coreutils list]

That was set by the gnu mailing as I didn't set a specific reply-to
and was sending to multiple lists.

>> We plan to release coreutils-8.23 next week, so any testing
>> you can do on various different systems between now and Thursday
>> would be most welcome.
>>
> 
>> To test follow this standard procedure:
>>
>>   tar -xf $downloaded_file
>>   cd coreutils-8.22.151-37b36
>>   ./configure && make check VERBOSE=yes
> 
> On 32-bit cygwin, a default ./configure didn't even get to 'make check'
> due to this error:
> 
>   CCLD     src/make-prime-list.exe
> make[2]: *** No rule to make target 'src/libstdbuf.so', needed by
> 'all-am'.  Stop.

Hmm, I'm guessing the make level failure is related to EXEEXT.
Notice how bin_PROGRAMS is adjusted in configure.ac
Probably pkglibexec_PROGS would need to be adjusted similarly.
Though that would not be the only thing needed to support the
stdbuf LDPRELOAD scheme on cygwin.
So perhaps this would avoid the immediate issue?

diff --git a/configure.ac b/configure.ac
index b50f6e1..68bc011 100644
--- a/configure.ac
+++ b/configure.ac
@@ -473,7 +473,7 @@ AC_COMPILE_IFELSE(
   [stdbuf_supported=yes],
   [stdbuf_supported=no])
 AC_MSG_RESULT([$stdbuf_supported])
-if test "$stdbuf_supported" = "yes"; then
+if test "$stdbuf_supported" = "yes" && test -z "$EXEEXT"; then
   gl_ADD_PROG([optional_bin_progs], [stdbuf])
 fi


> Trying again with
>  ./configure --enable-no-install-program=arch,coreutils,hostname,stdbuf
> 
> lets the testsuite run:
> 
> # TOTAL: 563
> # PASS:  365
> # SKIP:  152
> # XFAIL: 0
> # FAIL:  42
> # XPASS: 0
> # ERROR: 4
> 
> I'm attaching the results.  Most of the failures are not flaws in
> coreutils proper, but limitations in cygwin itself (aka gaps where
> cygwin is unable to supply proper posix semantics).  I'll try and look
> closer at the failures, to see if there are any obvious fixes for upstream.

The ERRORS and some of the FAILs are due to xargs failing with:
  "xargs: environment is too large for exec"
Perhaps that's triggered by find_exe_basenames_() in init.sh ?

> At this point, it's probably not worth holding up the release for
> cygwin; I can probably patch around the worst of it, and will be
> providing pre-built binaries for cygwin whether or not the final 8.23
> release has fixed any of these problems.  Although a quick fix that
> disabled stdbuf on platforms where it can't be built might be nice, it
> certainly doesn't qualify as a recent regression.

This is a good point to sync up cygwin, since this will probably
be the last of the 8.x series.

thanks!
Pádraig.