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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net