[Toybox] The cut -C test is failing because bionic's wcwidth() doesn't match glibc or musl.

[Rob Landley]

On 10/20/21 4:35 PM, enh wrote:
> On Tue, Oct 19, 2021 at 11:56 PM Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
>     On 10/19/21 10:57 AM, enh wrote:
>     > my guess is that you're using a statically-linked binary?
> 
>     Yup. I can't test dynamic bionic on devuan, bionic isn't installed in /lib.
> 
> if you don't mind creating a /system directory (or symlink) in /, you can just
> run like that. there's a script in AOSP bionic that sets up all the links you
> need to run the bionic tests on the host.

[Removed flailing trying to find the script, you said where it is later.]

Does it fix the OTHER warnings about being unable to "__bionic_open_tzdata:
couldn't find any tzdata when looking for utc!" and such? I still need to fix
the "FAIL: find -type f -user -exec" because bionic can't read my $USER out of
/etc/passwd...

Ahem:

env: exec env: No such file or directory
PASS: env -i

Right, you disabled builtins, and there's no $PATH. I should $(which env) there.
And maybe add an || echo fail

(And now having done the $(which) annd checked it in... "env -i env" on the host
does NOT have this failure. The -i does not apply to env's own exec. Sequencing
I need to fiddle with...)

All the other failures seem to be the unicode plumbing.

>     (And when I _tried_ to create a chroot as a normal user, bionic segfaulted
>     before calling main() because /dev/null wasn't there. Did that ever get fixed?
>     Hard to run an init linked against bionic when that's the case. 
> 
> have you tried? i'm pretty sure there's a special case for pid 1, for exactly
> this reason :-)

I'm going to give you a moment to think about what you did.

>     The kernel guys
>     never merged my https://lkml.org/lkml/2017/9/13/651
>     <https://lkml.org/lkml/2017/9/13/651> stuff. I gave 'em three
>     strikes and moved on. I have a todo item to teach cpio to hallucinate /dev
>     nodes...)
> 
>     > bionic doesn't have a
>     > "static libdl", so when it tries to dlopen() icu4c to handle an i18n question,
> 
>     ... why would it need to do that?
> 
> because the last thing the world needs is _multiple_ copies of all the i18n
> data. icu is the source of truth for that on Android. (we've had bugs in the
> past in this area that made us clean up our act.)

It's the dlopen() that hurts. I'd ask why there's no libicu.a, but the r21d ndk
doesn't seem to have a libicu.so either. I should grab a newer version...

Static linking is a legitimate use case. Android does not particularly treat it
as such, but I'm going to keep periodically tapping the sign.

>     Not sure if I _should_, but I _can_. (It was nice to leave this to libc. Then it
>     wasn't my problem to update it every time Microsoft wrote another check to the
>     unicode committee. Both glibc and musl can do this when statically linked.
>     Sigh.)
> 
> i'll only send a patch so i can disable this again on Android even if you _do_
> do it, so i don't think it's a great use of your limited time :-)

Oh there'd have been a config symbol, but I'd mostly convinced myself it's not
worth it even before Rich's email.

(The utf8 parsing was something glibc/musl/bionic all did differently, it was
tiny anyway, and has changed only once since it was invented. The unicode stuff
glibc and musl currently seem to do right, it's tractable but not trivial, it
changes with the weather, and I am literally directly complaining to the person
who maintains the one that fails.)

> hang on, let me look out the symlink script... here you go:
> 
> https://android.googlesource.com/platform/bionic/+/master/build/run-on-host.sh

I was hoping that after the aosp build there'd be a system directory that I
could ln -s /system to and it would just work. Instead:

  # source this script in bash

  source ${ANDROID_BUILD_TOP}/build/envsetup.sh

So we have to do the envsetup in order for $ANDROID_BUILD_TOP to be set, and
then this script does it _again_. Right.

Before I run something that makes this many assumptions as root so it can make
presumably persistent changes to my host system, I think I'm going to try to
read it a little more closely. Thanks for the pointer.

> that should set you up with everything you need (and both 32- and 64-bit too, if
> you're chasing something 32-bit-only).

It declares a shell function, and then doesn't call it. What it DOES do is eval
a soong invocation, and says to read envsetup.sh (which is just under 2000 lines
long) to figure out what --dumpvars-mode does (that env and declare -p
presumably don't).

Probably not tonight.

Rob