<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 21, 2021 at 12:18 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/20/21 4:35 PM, enh wrote:<br>
> On Tue, Oct 19, 2021 at 11:56 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> On 10/19/21 10:57 AM, enh wrote:<br>
> > my guess is that you're using a statically-linked binary?<br>
> <br>
> Yup. I can't test dynamic bionic on devuan, bionic isn't installed in /lib.<br>
> <br>
> if you don't mind creating a /system directory (or symlink) in /, you can just<br>
> run like that. there's a script in AOSP bionic that sets up all the links you<br>
> need to run the bionic tests on the host.<br>
<br>
[Removed flailing trying to find the script, you said where it is later.]<br>
<br>
Does it fix the OTHER warnings about being unable to "__bionic_open_tzdata:<br>
couldn't find any tzdata when looking for utc!" and such? I still need to fix<br>
the "FAIL: find -type f -user -exec" because bionic can't read my $USER out of<br>
/etc/passwd...<br>
<br>
Ahem:<br>
<br>
env: exec env: No such file or directory<br>
PASS: env -i<br>
<br>
Right, you disabled builtins, </blockquote><div><br></div><div>yeah, to try to reduce mksh/toybox confusion. if/when we switch /bin/sh to toybox it should reduce compat issues too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and there's no $PATH. I should $(which env) there.<br>
And maybe add an || echo fail<br>
<br>
(And now having done the $(which) annd checked it in... "env -i env" on the host<br>
does NOT have this failure. The -i does not apply to env's own exec. Sequencing<br>
I need to fiddle with...)<br>
<br>
All the other failures seem to be the unicode plumbing.<br>
<br>
> (And when I _tried_ to create a chroot as a normal user, bionic segfaulted<br>
> before calling main() because /dev/null wasn't there. Did that ever get fixed?<br>
> Hard to run an init linked against bionic when that's the case. <br>
> <br>
> have you tried? i'm pretty sure there's a special case for pid 1, for exactly<br>
> this reason :-)<br>
<br>
I'm going to give you a moment to think about what you did.<br></blockquote><div><br></div><div>yeah, it's one of those things that's hard to reason about --- "does my tiger-repellant bracelet actually work, or are there just no tigers where i live?". specifically "has Android never had a stdio confusion CVE because of this, or because the world had already moved on from those security bugs [which were all the rage when Android started], or just because we don't have anything like inetd?". hard to untangle those, and since security -- like law -- is an ass-covering business, no-one wants to be the one to _remove_ anything, even if it's not obvious that it's really helping. (and in this case it's not obvious that it's _not_ helping, so...)</div><div><br></div><div>/me wonders whether i could at least replace the special case with a fallback that uses open() with O_TMPFILE?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> The kernel guys<br>
> never merged my <a href="https://lkml.org/lkml/2017/9/13/651" rel="noreferrer" target="_blank">https://lkml.org/lkml/2017/9/13/651</a><br>
> <<a href="https://lkml.org/lkml/2017/9/13/651" rel="noreferrer" target="_blank">https://lkml.org/lkml/2017/9/13/651</a>> stuff. I gave 'em three<br>
> strikes and moved on. I have a todo item to teach cpio to hallucinate /dev<br>
> nodes...)<br>
> <br>
> > bionic doesn't have a<br>
> > "static libdl", so when it tries to dlopen() icu4c to handle an i18n question,<br>
> <br>
> ... why would it need to do that?<br>
> <br>
> because the last thing the world needs is _multiple_ copies of all the i18n<br>
> data. icu is the source of truth for that on Android. (we've had bugs in the<br>
> past in this area that made us clean up our act.)<br>
<br>
It's the dlopen() that hurts. I'd ask why there's no libicu.a, but the r21d ndk<br>
doesn't seem to have a libicu.so either. I should grab a newer version...<br></blockquote><div><br></div><div>icu4c in apps is ... complicated. but you're never getting a *static* icu4c for the same "the icu data format and schema aren't stable" reasons i've mentioned before.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Static linking is a legitimate use case. Android does not particularly treat it<br>
as such, but I'm going to keep periodically tapping the sign.<br></blockquote><div><br></div><div>it's a legitimate use case _if you're prepared to carry everything around yourself_. and that is supported --- feel free to build your own icu4c and ship your own 30MiB data file :-)</div><div><br></div><div>(we did finally get a stable supported subset of the icu4c API for apps into the NDK for S aka 12, but that doesn't help your use case.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Not sure if I _should_, but I _can_. (It was nice to leave this to libc. Then it<br>
> wasn't my problem to update it every time Microsoft wrote another check to the<br>
> unicode committee. Both glibc and musl can do this when statically linked.<br>
> Sigh.)<br>
> <br>
> i'll only send a patch so i can disable this again on Android even if you _do_<br>
> do it, so i don't think it's a great use of your limited time :-)<br>
<br>
Oh there'd have been a config symbol, but I'd mostly convinced myself it's not<br>
worth it even before Rich's email.<br>
<br>
(The utf8 parsing was something glibc/musl/bionic all did differently, it was<br>
tiny anyway, and has changed only once since it was invented. The unicode stuff<br>
glibc and musl currently seem to do right, it's tractable but not trivial, it<br>
changes with the weather, and I am literally directly complaining to the person<br>
who maintains the one that fails.)<br>
<br>
> hang on, let me look out the symlink script... here you go:<br>
> <br>
> <a href="https://android.googlesource.com/platform/bionic/+/master/build/run-on-host.sh" rel="noreferrer" target="_blank">https://android.googlesource.com/platform/bionic/+/master/build/run-on-host.sh</a><br>
<br>
I was hoping that after the aosp build there'd be a system directory that I<br>
could ln -s /system to and it would just work. Instead:<br>
<br>
# source this script in bash<br>
<br>
source ${ANDROID_BUILD_TOP}/build/envsetup.sh<br>
<br>
So we have to do the envsetup in order for $ANDROID_BUILD_TOP to be set, and<br>
then this script does it _again_. Right.<br></blockquote><div><br></div><div>(fwiw, i think that's for the buildbots.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Before I run something that makes this many assumptions as root so it can make<br>
presumably persistent changes to my host system, I think I'm going to try to<br>
read it a little more closely. Thanks for the pointer.<br></blockquote><div><br></div><div>oh, yeah, to be clear: i was suggesting you boil this down to the three or four lines you actually need (since aiui part of your goal is to _not_ have to have a complete AOSP checkout that's up to date and built).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> that should set you up with everything you need (and both 32- and 64-bit too, if<br>
> you're chasing something 32-bit-only).<br>
<br>
It declares a shell function, and then doesn't call it. What it DOES do is eval<br>
a soong invocation, and says to read envsetup.sh (which is just under 2000 lines<br>
long) to figure out what --dumpvars-mode does (that env and declare -p<br>
presumably don't).<br></blockquote><div><br></div><div>yeah, you just need the `ln -s`s. if you follow the history far back enough, it used to basically just be that, but things got a lot more complicated to support all the different kinds of builds, and the multiple supported build environments (bots versus humans in particular).</div><div><br></div><div>if you just manually do the `ln -s` for /system/bin and /system/lib64 (and /system/lib if you care about 32-bit), you're most of the way there, and i think the error messages you get when you run will point you at the other bits (tz data?).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Probably not tonight.<br>
<br>
Rob<br>
</blockquote></div></div>