[PATCH] some Mac OS X fixes

[Rob Landley]

On Friday 17 February 2006 10:53 pm, Devin Bayer wrote:
> On Feb 17, 2006, at 17:15, Rob Landley wrote:
> > On Friday 17 February 2006 2:45 am, Devin Bayer wrote:
> >> I wanted to do a little busybox hacking on my laptop recently and
> >> found it didn't even compile on OS X.  This patch fixes those bugs
> >> blocking my development, but it doesn't go far enough to make busybox
> >> useful on OS X.  It touches lots of different files, but most of the
> >> changes are too minor for individual patches.  A summary of the
> >> fixes:
> >>
> >> * Don't try to make empty archives
> >
> > What exactly is wrong with that?
>
> $ ar cru ifeelemptyinside.a
> ar: no archive members specified (exit status 1)
>
> >> * wait is the name of a function - don't use variables with that name
> >
> > Which header is that prototyped in?  Can we avoid #including it?
>
> sys/wait.h is included by stdlib.h, so no luck.
>
> >> * bb_strlen called strlen which was a macro to bb_strlen.  How did
> >> this
> >>    ever work for anybody?
> >
> > Up until yesterday there was an #undef there.  Vodz just removed
> > it.  I don't
> > know why.
>
> OK, understood.  But I removed the kludge altogether because it
> didn't seem necessary.  I'm guessing  it's to save space.  But
> doesn't -fno-inline-strlen work just as well?

I'll look into it.

> > That said, I don't think losetup is ever going to work on MacOS X.
> > And lots
> > of our applets get data out of /proc, which macos X doesn't have.
> > At best
> > you're only ever going to build a subset.
>
> That's why I said "mostly" short-term.  losetup is useless, but most
> of the applets getting data out of /proc could be re-written to not
> be proc-centric.

How?

There are embedded Linux systems that want to trim out /proc to save space 
that might also benefit from this.  I'm not against the idea.  I'm just not 
sure how else to do it in a small simple way...

> Then the libbb function could either get the data 
> out of proc or if on OS X, get it the OS X way.

From an architectural standpoint, I'd like to confine platform specific 
changes to #platform.h making all the actual "#ifdef MACOSX" checks, and some 
kind of platform.c file (macosx.c, linux.c) for support code.

I'd like to avoid the code having #ifdef __linux__ sprinkled through the 
bodies of the functions, if at all possible.  (In fact there are some 
existing glibc version checks I want to clean out...)

> >> * SUSv3 doesn't require -lcrypt - nor does OS X even have it
> >
> > Does it have the functionality?
>
> SUSv3 defines encrypt, setkey, and crypt.  Mac OS X has those and
> des_ varients.  I don't have any idea about their behavior.  My
> concern was with failing to link against the non-existant libcrypt
> and also including the obsolete header crypt.h.

We have built in md5 and sha1 code, and the fallback obsolete crypt stuff for 
passwd isn't really all that important.  Possibly we can just remove it and 
use the built-in functions...

> >> * OS X uses different macros for endian-detection
> >
> > We have a #platform.h to hide those kind of differences...
>
> OK, it doesn't mention anything about endianness,

It should. :)

> so you could 
> probably just move my patch from hash_fd.c to platform.h.  What
> should the standard busybox way be of detecting endianness?  I
> suggest BB_BIG_ENDIAN = 0|1 and use that for all the tests.

I have no objection to that.

> > Much as I'm interested in getting busybox to work on MacOS X, it's
> > going to
> > take me a little while to work through a patch this big doing this
> > many
> > different things...
>
> Well, if there's anyway I can help...  I need SHA1 and MD5 functions
> exported.  You said before you were working on that.

Yeah, the passwd.c rewrite tito did is sitting on my hard drive half reviewed.

There's a tangled mess in libbb/hash_fd.c that contains sha1 and md5sum code 
needs to be untangled and made to work on a memory buffer as well as just a 
filehandle.

I'm drowning in to-do items, as usual... :)

> Would I be 
> stepping on your toes if I went ahead and submitted a patch to do
> just that?

If you want to untangle libbb/hash_fd.c, feel free.  It needs it.

Also, if you could untangle the "only build libraries if anything uses them" 
from your big patch and submit just that as a separate patch, I can apply 
that now without thinking too deeply about it. :)

Rob
-- 
Never bet against the cheap plastic solution.