[Top][All Lists]

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

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

From: Markus Duft
Subject: Re: Fwd: Re: [Platform-testers] new snapshot available: coreutils-8.12.178-df9cd
Date: Thu, 08 Sep 2011 07:44:32 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110706 Lightning/1.0b3pre Thunderbird/3.1.10

On 09/07/11 16:13, Jim Meyering wrote:
> Markus Duft wrote:
> ...
>> 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.

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

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


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

Attachment: chroot-setgroups.patch
Description: Text Data

reply via email to

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