svn commit: trunk/busybox/include

[Denys Vlasenko]

On Thu, Sep 25, 2008 at 11:47 AM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Thursday 25 September 2008, Denys Vlasenko wrote:
>> With attached .config:
>>
>>   CC      libpwdgrp/pwd_grp.o
>> cc1: warnings being treated as errors
>> libpwdgrp/pwd_grp.c: In function 'bb_internal_initgroups':
>> libpwdgrp/pwd_grp.c:665: error: implicit declaration of function
>> 'setgroups' make[1]: *** [libpwdgrp/pwd_grp.o] Error 1
>> make: *** [libpwdgrp] Error 2
>>
>> Maybe frame setgroups decl in #ifdef DARWIN thingy?
>
> ugh, no ... this is a failing of busybox.  it is purposefully not pulling in
> grp.h and thus not getting the setgroups() prototype when the internal
> pwd/grp stuff is enabled.  if you want to continue the "ignore it" route,

I don't understand you. setgroups is orthogonal to most of other grp.h
things in a sense that it is not tied to the method of storage for
user/group database. It is used to tell kernel what group vector
is in effect. It makes sense to have private implementation of
user/group database (libpwdgrp) yet still use setgroups() from libc.

> then the prototype should be limited to that ifdef logic (i dont use the bb
> pwd/grp replacement code so i wouldnt notice it failing in that case).

> of course, if the build/host include paths werent so intertwined, it wouldnt
> be nearely as much of a problem ... we have to make sure libbb.h
> is "portable" because it gets pulled in by the applet generation code
> (applets/usage.c).  sticking random system prototypes into libbb.h makes this
> very fragile.

Yes, just declaring setgroups() there like it is done now
is not a correct way. Better ideas?
--
vda