On Thu, Sep 25, 2008 at 11:47 AM, Mike Frysinger <[EMAIL PROTECTED]> 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 _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
