coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cygwin results [was: [platform-testers] new snapshot available: coreutil


From: Eric Blake
Subject: cygwin results [was: [platform-testers] new snapshot available: coreutils-8.22.151-37b36]
Date: Mon, 14 Jul 2014 22:04:33 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 07/14/2014 07:33 PM, Pádraig Brady wrote:

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

Possible; I'll give it a shot.  At this point, it requires a full
autoreconf, so I spent some time getting coreutils.git up and running
rather than just building from the snapshot.

Now I'm seeing this with gcc 4.8.3:

  CC       lib/openat-die.o
lib/openat-die.c: In function 'openat_save_fail':
lib/openat-die.c:34:1: error: function might be candidate for attribute
'noreturn' [-Werror-suggest-attribute=noreturn]
 openat_save_faile (int errno)
 ^

Looks like something to patch in gnulib.  I wonder what's going on here,
since cygwin DOES have openat(), so I'm not sure why gnulib is wanting
to replace it (not like other systems where the function is lacking
altogether).


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

I'll try and take a look at that as well.

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

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]