On 09/07/11 16:13, Jim Meyering wrote:
> Markus Duft wrote:
> ...
[snip]
>> 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?
those functions behave exactly like their non-_nomembers counterparts, except,
that they don't fetch _all_ group members from the domain controller. in my
case for example, we have > 300 users in the domain, which makes each call to
the normal versions take > 3 seconds. i'd suggest a test for those in
configure, and if they exist, use them. i'm unsure on how such a test could
look like though, my m4-foo is not strong enough ;)
>
[snip - setgroups patch]
>
> Does Interix really lack this capability?
>
sad but true ...
> If so, I would rather something like this, that adds a
> dummy, always-successful setgroups function.
> (maybe also "using" the parameters)
mhm. new patch attached.
>
[snip]
>>
>> +#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?
gcc is 4.2.4 and there is no chance to get a newer one to work currently (i
have big problems forward porting my patches). but i /think/ it's the library
support anyway thats broken. it seems to be somewhere in the printing (fprintf,
sprintf). if i run an unpatched "seq 1 10", i get this:
mduft coreutils-8.12.193-d8dc8 $ ./src/seq 1 10
0
0
-2
0
-0
-2
-26815615859885194199148049996411692254958731641184786755447122887443528060147093953603748596333806855380063716372972101707507765623893139892867298012168192
0
-0
-0
in [1], Bruno Haible suggested some test from the gnulib test-suite, with which
i can investigate the problem more deeply, which i'm now doing (as time allows).
[1] http://lists.gnu.org/archive/html/bug-gnulib/2011-06/msg00136.html
regards, Markus
>
> 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
diff -ru -x '*.o' coreutils-8.12.193-d8dc8.orig/src/chroot.c coreutils-8.12.193-d8dc8/src/chroot.c
--- coreutils-8.12.193-d8dc8.orig/src/chroot.c 2011-09-07 07:59:27 +0200
+++ coreutils-8.12.193-d8dc8/src/chroot.c 2011-09-08 07:16:51 +0200
@@ -52,6 +52,17 @@
{NULL, 0, NULL, 0}
};
+#ifdef __INTERIX
+/* Interix lacks supplemental group support. A dummy, always successful
+ * replacement is added here to avoid the need to check for setgroups,
+ * just to support such a broken platform. */
+static int setgroups(size_t size, gid_t const *list)
+{
+ (void)size; (void)list;
+ return 0;
+}
+#endif
+
/* 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
