1.13.0 coreutils/id.c calls libc getgrouplist()

walter harms wharms at bfs.de
Sat Nov 15 20:48:16 UTC 2008



Tito schrieb:
> 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.
> 

i am guilty also :) since i started patching id, what was the starting reason
you did the rewrite. i think a patch is not needed anymore since the needed ulibc is out now.

my (only) point was that we should not release SW that needs a ulibc version
(a supported libc!) that is not yet released. I am fully aware why this bad
timing happened but this is simply a bad habit, no matter what, you can not do that.
i thought is important to communicate that.

re,
 wh






More information about the busybox mailing list