Keith Packard

It looks like glibc (and hence libgcc) doesn't actually have soft float support for 80-bit values. Looks like we either need to fix that, or bail on long double support...

This would be cool, but I fear it would be very difficult to prevent abuse and make it secure.

[Katie Bell just gave a presentation at LCA 2022](https://lca2022.linux.org.au/schedule/presentation/33/) where she compiled CPython with enscripten to wasm and ran the result in a browser. I suspect doing that for snek...

As you can see, I hacked up the posix port to allow it to be built without readline so that it can be linked -static. If you're up for trying...

The pre-built library follows the default configuration for picolibc so that it matches other toolchains that include picolibc, including ARM LLVM, Debian, crosstool-ng and the ARM GNU toolchains. Note that...

Yup, I'm not saying the sdk config shouldn't be changed to match what Zephyr users expect, just explaining where the current settings came from.

Yup, version 1.8.5 provides pre-built versions of all of the printf modes supported by current Zephyr configurations.

I'd certainly welcome contributions like this -- would be great to have the POSIX Snek also able to drive peripherals! If someone wants to give this a try, I will...

> Ah okay, got it, much clearer now. Thank you very much. The issue then seem to be simply resolvable by adding microblaze to support cpus list. What comes next...

there's a bug with arm v8.1m PACBTI support in gcc14, and as gcc14 includes that as a default multi-lib target, it would be good to include the fix from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780