[Toybox] [PATCH] Make it easier to switch regex implementations.

[Rob Landley]

On 11/10/20 6:02 PM, enh wrote:
>> He can't tell you what your _objectives_ are, but if you want libc host
>> compatibility domain expertise, that's the guy who knows where the bodies are
>> buried.
> 
> no, it's actually stuff like "non-Android keeps its list of users in
> /etc/passwd"
>
> and "non-Android doesn't have a netd daemon that all DNS
> queries should go via" and so on.

Ah. That's the part Khem Raj gave annual tutorials about at ELC, dunno if he's
kept current now he's working at Comcast. Ah, sorry, they're "Altria" now.

My question is more "compatibility with what"? Neither sounds like it would hit
hermetic builds, which run as a normal user (so aren't looking up a lot of UIDs,
and you just said you got a patch for that one anyway) and all the source
downloads should get handled by repo and then you can build in a netless
container. It's not hermetic otherwise, or even reproducible. (Plus "static DNS
doesn't work" is something glibc shares anyway, it tries to dlopen() helper
libraries from a static context and hits the two heap problem. Static glibc
would be "lateral progress", a thing I've railed about in the Linux world for
years...)

Trying it out in a fork to see what breaks doesn't seem like a bit lift, and you
have the Giant Test Harness of Doom, but maybe I could try it here first...

https://android.googlesource.com/platform/external/qemu/+/master/docs/PREBUILT-BINARIES.TXT

Hmmm...

  ~/android/aosp$find . -name android-rebuild*
  ~/android/aosp$

Nope. *shrug* Project not staffed/funded is a song I know well, and "users show
up making demands once a thing exists" is a thing. But static bionic is already
in the NDK and I _have_ built binaries with it for a while now...

> host bionic _is_ actually in use for some things already. it's just
> not used for a wide _variety_ of tasks, so there are probably still
> bits that don't work that just haven't been used yet.

Exactly. But if "hermetic NDK build" is one of them, it's probably either toybox
(send me the bug report, I fix) or the llvm suite (half of which you're using
natively on target already)...

I'd to poke at this more myself, but domain expertise aside when I can cycle
back to regularly putting hours into toybox I need to finish toysh, cleanup and
promote netlink-api route, and $DAYJOB needs stty, dhcp client, and sysvinit.
Plus dd is just EMBARASSING. And THEN I need to glue the musl-cross-make native
toolchains into the mkroot output and get LFS 10 to build under it, which needs
AWK which is probably the largest remaining can of worms...

Alas, if I try building new static toybox binaries with the NDK myself and
swapping them in for the prebuilts to see if android builds, I couldn't properly
test the result so all it would prove would be lack of build break. That's why
AOSP still lives after Linux From Scratch in my todo heap: traversing the full
LFS build is a simpler (and more easily penetrable) problem than the AOSP build.

That said, if I get LFS working with mcm I could try it with a static NDK toybox
build... :)

Rob