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

[Markus Duft]

On 09/08/11 10:17, Jim Meyering wrote:
> Markus Duft wrote:
> 
[snip]
> 
> A simpler approach might be ok: add a test for existence of the
> _nomembers functions (in m4/jm-macros.m4), and then add code like
> this for each in system.h, inserted after the declaration of getgrgid:
> 
>   /* Add a comment here, justifying this, based on what you
>      said above.  */
>   #if HAVE_GETGRGID_NOMEMBERS && ! HAVE_SETGROUPS
>   # define getgrgid(n) getgrgid_nomembers(n)
>   #endif
> 
>   #if HAVE_GETGRNAM_NOMEMBERS && ! HAVE_SETGROUPS
>   ...
> 
> Please include a complete patch that I can apply with
> "git am FILE", per instructions in HACKING:
> 
>     http://git.sv.gnu.org/cgit/coreutils.git/tree/HACKING

ok. setgroups is not needed here, as it something different. i have 2 commits 
on top of current master now (attached).

i'll investigate on the long double problem some more. currently i think, that 
it could be the case, that libc has been built with a compiler with 64bit long 
doubles, whereas the current gcc has 128 bit long double (not verified yet 
though). i'll have a look... :)

regards,
markus

> 
>>>> +#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).
> 
> Please pursue that first.
> If improving the printing or conversion functions in gnulib
> can solve your problem, then making changes to coreutils would
> be counterproductive.
> 
>> diff -ru -x '*.o' coreutils-8.12.193-d8dc8.orig/src/chroot.c 
>> coreutils-8.12.193-d8dc8/src/chroot.c
> 
> I suggested to use #if ! HAVE_SETGROUPS, yet you used #ifdef __INTERIX.
> Why?
> 
>> +#ifdef __INTERIX
> 
> Using "#ifdef ANYTHING_HARDWARE_SPECIFIC" is best avoided.
> We prefer so-called feature tests like "#if ! HAVE_SETGROUPS",
> because then when some other system with the same problem comes
> along, rather than having to adjust every #ifdef like this:
> 
>   #if defined __INTERIX || defined __other_broken_system
> 
> our "#if ! HAVE_SETGROUPS" just works.
> That is much more scalable from the software engineering/maintenance
> point of view.
> 
>> +/* 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

0001-add-check-for-setgroups-which-may-be-missing-on-some.patch
Description: Text Data

0002-add-support-for-getgr-_nomembers-functions-on-interi.patch
Description: Text Data