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