[Toybox] FreeBSD Toybox check-in

[Ed Maste]

On Thu, 9 Nov 2023 at 13:57, Rob Landley <rob at landley.net> wrote:
>
> On 11/8/23 17:04, Ed Maste wrote:
> > I dropped off the mailing list a while back due to bounced mail, and
> > hadn't been able to look at Toybox for some time. I recently had
> > occasion to check on the state of Toybox on FreeBSD again.
>
> I have a freebsd image running under qemu, which I do occasionally test on. :)

Great. As always, if you run into anything that seems strange on
FreeBSD I'm very interested in that sort of feedback. FreeBSD 14.0 is
releasing soon.

> I just switched to $(MAKE) in the Makefile so it should pass along gmake.

I rebased an old commit from way back that changed a bunch of sed
invocations to gsed, make to gmake etc. and almost all of them
disappeared on rebase. There is one `make` left in ./configure which
doesn't matter much (of course, since it doesn't need to be used).

> > Other than that, `gmake allnoconfig
> > KCONFIG_ALLCONFIG=kconfig/freebsd_miniconfig && gmake` is successful.
>
> $ make help | grep -i bsd
>   bsd_defconfig   - Select commands known to build on freebsd
> $ grep -m1 -A1 bsd kconfig/Makefile
> bsd_defconfig: $(obj)/conf $(KCONFIG_TOP)
>         KCONFIG_ALLCONFIG=$(obj)/freebsd_miniconfig $< -n $(KCONFIG_TOP) > /dev/null
>
> In theory you should be able to "make bsd_defconfig toybox".

Indeed, thanks for the note.

> > There are a number of toys (or config options) that are not currently
> > enabled in freebsd_miniconfig, but do build, on my FreeBSD 14 laptop:
>
> Several of those are in pending. I'm happy to add the ones that are NOT in
> pending to the defconfig.

Sounds good. I just wanted to find everything that builds on FreeBSD,
but this definitely doesn't make sense when actually using toybox.

FWIW It looks like toybox in the FreeBSD ports collection contains a
patch to enable shuf (but not any of the other ones that worked for
me).

> > A few toys are disabled but would be nice to have -- at least cp, mv,
> > install, tar, uname.
>
> Hmmm, most of those are enabled for macos. We should figure out why those builds
> break and maybe fix them?
>
> cp/mv/install are the same plumbing with different UI.

Ah, these fail due to:
toys/posix/cp.c:128:18: error: call to undeclared function
'xattr_flist'; ISO C99 and later do not support implicit function
declarations [-Werror,-Wimplicit-function-declaration]
(and xattr_fget, xattr_fset). On FreeBSD these are extattr(2) and
should need only a small patch in portability.c.

> No idea why tar is unhappy? (Possibly the sparse or selinux stuff?)

Similar issue, xattr_lget and xattr_get. And error: use of undeclared
identifier 'ENODATA'

> Ah, uname.c also has arch and linux32 shoved in there, and linux32() is calling
> personality(PER_LINUX32) which you probably don't have (either the function or
> the macro name). I could stick an #ifdef clause in portability.h?

Yep, we have no personality(2).

> Also, if I _do_ stick a #define personality(x) ; in portability.h for freebsd,
> then linux32 would build but be a NOP. This is not unique and is why "it builds
> for freebsd" and "it does anything interesting" are two different things to test. :)

Yes, definitely. Right now I'm building toybox and experimenting for
its own sake, more testing is definitely called for before actually
using it.

> Still dunno what to do about the "/usr/bin/env is cannon but /bin/bash is not"
> weirdness, especially given that a lot of Linux systems started symlinking
> /usr/bin to /bin some years ago... (Yeah, partially my fault, but still...)

Yes. In the fullness of time I expect we'll make the same (symlink)
change in FreeBSD, but it still won't help here, because on FreeBSD
bash is /usr/local/bin/bash.