svn commit: trunk/busybox/include

Mike Frysinger vapier at gentoo.org
Fri Sep 26 04:53:31 UTC 2008


On Thursday 25 September 2008, Denys Vlasenko wrote:
> 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.busybox.net/pipermail/busybox/attachments/20080926/4897bead/attachment-0002.pgp 


More information about the busybox mailing list