compile problem with now shadow passwds

Rob Landley rob at landley.net
Mon Aug 14 00:04:07 UTC 2006


On Thursday 03 August 2006 4:16 pm, Max Okumoto wrote:
> Hi Rob,
>  
>  Did you have a chance to look at busybox with no shadow
>  passwd support compiling with uClibc with no shadow passwd support?

I'm just getting to it now.  (Bit behind. :)

I see svn 15766 from rpjday fixing the config typo, but it looks like your 
initial patch wasn't checked in.

Sigh, my mental map of this area of the code is the stuff I spent a couple 
weeks rewriting (now what, 3 months ago?), and really really need to finish.

>  It looks like uClibc does not have a shadow.h if it is
>  not configured.  And busybox still tries to compile the
>  shadow passwd routines even though they are not going
>  to be used.

Yeah, that's broken.

Hmmm...

> <UGLY HACK>
> Since I don't want shadow passwd support anyway.
> I commented out the #include "shadow_.h"  in libpwdgrp/pwd_grp.c and
> libpwdgrp/pwd_grp_internal.c

That fixed it for you?  Doesn't that code #include libbb.h, which #includes 
shadow_.h?

This code hasn't had its #includes cleaned up because I plan to _delete_ it.  
(Parsing lines of colon separated ascii text is _not_ brain surgery, and does 
_not_ require a separate library from parsing the colon separated ascii text 
in /etc/passwd.  It just doesn't.  Really.  Honest and truly...)

> The libpwdgrp/Makefile.in tries to compile the shadow library code anyway.
>  So I commented out LIBPWDGRP_MOBJS1 assignment. </UGLY HACK>

I have a tree where that entire directory is gone, but alas the result doesn't 
quite compile yet, and _this_ weekend I'm working on learning enough from 
Cross Linux From Scratch (and buildroot, where necessary) to build a 
reproducible cross-compiler toolchain as part of a revival of my Firmware 
Linux project.

Right now the best regression test I have for busybox making a development 
system that uses BusyBox in place of all the packages it can replace, and 
which rebuilds itself from source code under itself.  Unfortunately, I'd 
taken it apart to add cross-compiling and QEMU to the mix (test it on arm, 
from my x86 laptop!) and in the middle of that I got a job at a 
cross-compiling company that uses completely different technology (based on 
RPM, which I try not to get any of on me), and it's now been 8 months since 
I've actually had any combination of "remotely current" and "actually 
working" on this project...

And so, I poke.  If you wondering why I was distracted, cross-compiling is 
painfully fiddly.

It'll be in http://busybox.net/~landley/firmware when I have something to 
post.  Right now there's about the first 1/3 of a design document up there, I 
think.  (And a mercurial repository, but that's not linked from index.html 
yet. :)

Anyway: could you send me an actual patch that fixes it for you (and confirm 
that it does), and I'll confirm it doesn't break anything here and apply it.

>                       Max

Rob

> "Robert P. J. Day" <rpjday at mindspring.com> wrote: On Thu, 3 Aug 2006, Max 
Okumoto wrote:
> 
> > There also seems to be a typo in the loginutils/Config.in
> >
> > Index: loginutils/Config.in
> > ===================================================================
> > RCS file: /opt/cvs/busybox/loginutils/Config.in,v
> > retrieving revision 1.1.1.2
> > diff -u -r1.1.1.2 Config.in
> > --- loginutils/Config.in        9 Jul 2006 19:10:12 -0000       1.1.1.2
> > +++ loginutils/Config.in        3 Aug 2006 10:55:30 -0000
> > @@ -14,7 +14,7 @@
> >           publicly readable.
> >
> >  config CONFIG_USE_BB_SHADOW
> > -       bool #"  Use busybox shadow password functions"
> > +       bool "  Use busybox shadow password functions"
> >         default y
> >         depends on CONFIG_USE_BB_PWD_GRP && CONFIG_FEATURE_SHADOWPASSWDS
> >         help
> >
> 
> applied.  (i'm guessing that really is a typo.  i was wondering if it
> was meant to represent a comment but i'm pretty sure that's not the
> case.  if i've misunderstood it, someone feel free to clear things
> up and i can always undo it.)
> 
> rday
> 
> 

-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list