Re: Fwd: Re: [Platform-testers] new snapshot available: coreutils-8.12.178-df9cd

[Jim Meyering]

Markus Duft wrote:
...
> On 08/31/11 21:40, Jim Meyering wrote:
>> Wow.  There have been nearly 1000 commits in *gnulib* since coreutils-8.12.
>> With 178 in coreutils proper, that is well above average[*].
>> If all goes well, I'll release coreutils-8.13 early next week,
>> so please beat this up (i.e., test) on a whatever systems you can.
>
> beat up... well... you know interix, right? :D
>
> i have two small patches (i had those for previous versions
> too... guess i forgot to submit them somehow...). could you review
> those, and give me some feedback? also attached is a test-suite log
> for interix. there are some problems i dind't investigate any further
> so far.
>
> one thing i saw is, that "df /" doesn't work, possibly because on
> interix "/" is not in the list of mounted filesystems? only /dev/fs/C
> is there, and df will fail on any path not starting with this.
>
> also, one more thing i saw from the gentoo ebuilds: we're adding those
> to CFLAGS for building, as otherwise "id" will be dead slow on
> domain-controlled windows machines:
>  -Dgetgrgid=getgrgid_nomembers -Dgetgrent=getgrent_nomembers
> -Dgetgrnam=getgrnam_nomembers

It would help a lot if you would give more detail, if possible,
like why the new version is more efficient, and what (if any)
is the resulting difference in semantics?

> is there a sane way to get those into the coreutils configure/source?

Sure.  Add a configure-time test to detect that those get*
functions are inefficient, test for the existence of the
*_nomembers replacements, and when required, AC_DEFINE one
to the other.

It sounds like it'd be best to put this in its own function
in a new .m4 file.  That'll make it easier to share with
other projects via gnulib, eventually.

> diff -ru -x '*.o' coreutils-8.12.178-df9cd.orig/configure.ac 
> coreutils-8.12.178-df9cd/configure.ac
> --- coreutils-8.12.178-df9cd.orig/configure.ac        2011-09-01 10:31:45 
> +0200
> +++ coreutils-8.12.178-df9cd/configure.ac     2011-09-01 10:32:07 +0200
> @@ -199,7 +199,7 @@
>  fi
>
>  # SCO-ODT-3.0 is reported to need -los to link programs using initgroups
> -AC_CHECK_FUNCS([initgroups])
> +AC_CHECK_FUNCS([initgroups setgroups])
>  if test $ac_cv_func_initgroups = no; then
>    AC_CHECK_LIB([os], [initgroups])
>  fi
> diff -ru -x '*.o' coreutils-8.12.178-df9cd.orig/src/chroot.c 
> coreutils-8.12.178-df9cd/src/chroot.c
> --- coreutils-8.12.178-df9cd.orig/src/chroot.c        2011-09-01 10:31:48 
> +0200
> +++ coreutils-8.12.178-df9cd/src/chroot.c     2011-09-01 10:39:56 +0200
> @@ -52,6 +52,7 @@
>    {NULL, 0, NULL, 0}
>  };
>
> +#ifdef HAVE_SETGROUPS
>  /* Call setgroups to set the supplementary groups to those listed in GROUPS.
>     GROUPS is a comma separated list of supplementary groups (names or 
> numbers).
>     Parse that list, converting any names to numbers, and call setgroups on 
> the
> @@ -110,6 +111,7 @@
>    free (gids);
>    return ret;
>  }
> +#endif

Does Interix really lack this capability?

If so, I would rather something like this, that adds a
dummy, always-successful setgroups function.
(maybe also "using" the parameters)

#if ! HAVE_SETGROUPS
static int
setgroups(size_t size, const gid_t *list)
{
  return 0;
}
#endif

>  void
>  usage (int status)
> @@ -229,8 +231,10 @@
>        free (user);
>        free (group);
>
> +#ifdef HAVE_SETGROUPS
>        if (groups && set_additional_groups (groups))
>          fail = true;
> +#endif
>
>        if (gid != (gid_t) -1 && setgid (gid))
>          {
> @@ -244,6 +248,7 @@
>            fail = true;
>          }
>      }
> +#ifdef HAVE_SETGROUPS
>    else
>      {
>        /* Yes, this call is identical to the one above.
> @@ -253,6 +258,7 @@
>        if (groups && set_additional_groups (groups))
>          fail = true;
>      }
> +#endif
>
>    if (fail)
>      exit (EXIT_CANCELED);

> diff -ru -x '*.o' coreutils-8.12.178-df9cd.orig/src/seq.c 
> coreutils-8.12.178-df9cd/src/seq.c
> --- coreutils-8.12.178-df9cd.orig/src/seq.c   2011-09-01 10:31:48 +0200
> +++ coreutils-8.12.178-df9cd/src/seq.c        2011-09-01 11:00:42 +0200
> @@ -27,6 +27,21 @@
>  #include "quote.h"
>  #include "xstrtod.h"
>
> +#ifdef __INTERIX
> +// very very broken long double "support".

Thanks for the suggested patch, but what problem are you working around?
Is this due to insufficient compiler support?  Use a newer gcc?
Insufficient library support?  If that's it, then won't one of the
gnulib's replacement functions work for you?

I'm very reluctant to replace every use of "long double" with a made-up
type like dblmax_t only for Interix when there is so little justification.

> +typedef double dblmax_t;
> +# define xstrtod_max xstrtod
> +# define c_strtod_max c_strtod
> +# define dblmax_fmt_f "f"
> +# define dblmax_fmt_g "g"
> +#else
> +typedef long double dblmax_t;
> +# define xstrtod_max xstrtold
> +# define c_strtod_max c_strtold
> +# define dblmax_fmt_f "gf"
> +# define dblmax_fmt_g "Lg"
> +#endif