1.13.0 coreutils/id.c calls libc getgrouplist()

[Tito]

On Saturday 15 November 2008 10:51:44 walter harms wrote:
> 
> Rob Landley schrieb:
> > On Friday 14 November 2008 09:42:50 walter harms wrote:
> >> hhhmmm,
> >>
> >> releasing a code that depends on a libc version that is not released yet
> >> it not nice to users.
> > 
> > I suspect glibc had this years ago and that's what they were testing against.
> > 
> > I also note that uClibc had an -rc1, -rc2, and -rc3 in the month of october, 
> > and had stated on the mailing list the intention to have a release out at the 
> > end of October.  In reality, the busybox 1.13.0 and uClibc 0.9.30 releases 
> > were essentially synonymous.
> > 
> hi Rob,
> 
> that may be but if you require the latest feature of the latest release
> you should give the users a hint.
> 
> 
> 
> >> something like
> >>
> >> if uClibc version < 0.9.30
> >> 	you need version 0.9.30 at least
> >> 	exit
> >> end if
> >>
> >> may help also.
> > 
> > For a single applet?  (Other applets build fine against much older versions.)
> > 
> > Would you like to add tests for dietlibc, newlib+libgloss, and klibc as well?  
> > Plus the various BSDs people occasionally send in patches for, MacOS X, and 
> > mingw?
> > 
> > Plus the various non-x86 targets with varying functionality, such as the fact 
> > you can't build taskset on m68k under _any_ libc due to the lack of smp 
> > processor affinity syscalls?
> > 
> > Wanna keep all of the above in sync, for each applet, for each new release of 
> > every project?  And warn about gcc versions that miscompile things on various 
> > hardware targets?
> > 
> > Or we could just avoid going down that rathole entirely, and stay simple.  I 
> > like simple...
> 
> i do not call it *the solution*. Of cause you can not solve every problem.
> This was not intended. But you can help with obvious problems in basic stuff
> like ulibc. and if you aware that the last version of gcc will cause havoc
> why not add a warning ?
> With m68k i am not sure i would assume that m68k people will be aware that
> it has no smp processor affinity.
> 
> NTL is is not our business to decide about releases. Denys is the maintainer
> and if he does , he does it.
> IMHO it is unfair to say nothing when i (i do not speak for other people) think he
> made a mistake.
> 
> re,
>  wh
> 

Hi,
i'm the culprit!!  ;-)
As the checks for the missing of getgrouplist in uClibc were in
the code.......I would dare to say uglyfied the code and due to
the fact that i did an integral rewrite of id.c I removed them.
The main reason that made me decide to remove the ifdefs was that:

1) libc has getgrouplist
2) getgrouplist was added to libbbpwdgrp
3) getgrouplist was already in uClibc svn
     and the mantainer  was talking about releasing soon.

So for the sake of code cleaness I removed the ifdef hell.
In reality uClibc was 2 days late or we 2 days to early,
this is surely annoying, but was not intended to happen.
Now the problem is resolved anyway.....and we have 
clean, readable and maintenable code.

@Walter
Nonetheless if you want to add some warning or 
maybe some advice in the id help text feel free
to send a patch.

Ciao,
Tito