On Thursday 25 September 2008, Denys Vlasenko wrote: > 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.
i'm not making any statements about what is/isnt appropriate for internal implementation. i'm stating that guessing at a C library prototype is wrong. the standards we work with dictate what the API must provide. they allow crazy stuff to happen at the ABI level. i hit this recently where a system header actually redirected a function call to a different ABI symbol altogether via an asm() directive while still providing the required API. > > 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? there isnt much in the way of clean solutions when we're talking about half-replacing sub sections of a C library. one option might be to use #define's to "hide" the function prototypes that busybox provides an internal replacement for. #if ENABLE_USE_BB_PWD_GRP # define putspent HIDE_PROTOTYPE_putspent ... #endif #include <grp.h> #if ENABLE_USE_BB_PWD_GRP # undef putspent #endif at the very least, since we need the setgroups() prototype, it can be reduced to only providing when grp.h is not included -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
