enh-google

(i was going to try editing this locally just to confirm that nothing breaks, but it seems like we don't have a new enough libc++ in the platform to have...

> If each defgroup had a bug URL associated with it we'd know where to point them (and they'd hopefully find it themselves). yeah, good idea! that sounds like the...

> Github thinks mruby is mostly C but finds some C++ in there too, I dunno if that's true or not. it's just the fuzzer, based on https://llvm.org/docs/LibFuzzer.html which is...

> Funnily enough, Rob makes the code depend on GPLv3 bash (Yes there is a replacement in the works, but for now the build depends on there being GPLv3 code...

> Ah, the support horizon is 10 years and the last GPLv2 bash was 16 years ago, assumed that you needed GPLv3 bash (Especially since MacOS doens't even use bash...

> Android NDK 25b has utmp.h but not utmpx.h. Switching API would break building these on android. yeah, while i'm always skeptical of "obsolete", and even more skeptical of anything...

> That sounds reasonable to me. Let me get back to you with run-time detection and some considerations for minimizing platform specific code. pro tip: it turns out that `getauxval(AT_HWCAP)`...

i don't think riscv64 auto-vectorization is anything like as well developed as arm64 atm, so it's quite possible that the optimal strategy will be to use intrinsics in the short...

> In the meantime I've added support for dynamically detecting the presence of the vector unit on the CPU. (yeah, that lgtm.) > AFAIK that is mostly architecture independent and...

> remain unanswered. (Side note: I'm not sure if we have tested aarch64-sve for flac CGLAGS+='-march=armv8-a+sve') (fwiw i did try that earlier this year [https://android-review.googlesource.com/q/topic:%22armv9%22] but all i got for...