Support for newlib-nano? #2998

New issue

Open

opened 2026-06-10 01:04:03 -05:00 by projectgus · 3 comments

projectgus commented

2026-06-10 01:04:03 -05:00

(Migrated from github.com)

We've had some success building MicroPython with --specs=nano.specs, which links newlib-nano implementations to reduce binary size and memory footprint:
https://github.com/micropython/micropython/pull/19299

(Specifically we get up to 1624 bytes of flash and 960 bytes of RAM back!)

However support is technically incomplete the way we've implemented it, as it'd be better if all source files (including pico-sdk) were compiled with --specs=nano.specs to prepend the include/newlib-nano directory to the search path. (The actual impact seems minimal, but there's always the risk of some libc function being ABI incompatible as a result.)

Would you folks consider adding newlib-nano support to pico-sdk?

I'm aware you already have picolibc support, so understand if you don't want to support too many libc variants. 😁

We've had some success building MicroPython with `--specs=nano.specs`, which links newlib-nano implementations to reduce binary size and memory footprint: https://github.com/micropython/micropython/pull/19299 (Specifically we get up to 1624 bytes of flash and 960 bytes of RAM back!) However support is technically incomplete the way we've implemented it, as it'd be better if all source files (including pico-sdk) were compiled with `--specs=nano.specs` to prepend the `include/newlib-nano` directory to the search path. (The actual impact seems minimal, but there's always the risk of some libc function being ABI incompatible as a result.) Would you folks consider adding newlib-nano support to pico-sdk? I'm aware you already have picolibc support, so understand if you don't want to support too many libc variants. 😁

👍 1

kilograham commented

2026-06-10 09:55:53 -05:00

(Migrated from github.com)

we're fine with adding more - we can look at adding this (need to understand how it plays with all our compilers, and any gotchas with pico_libc_interface - though it sounds like it is working ok for you)

we're fine with adding more - we can look at adding this (need to understand how it plays with all our compilers, and any gotchas with `pico_libc_interface` - though it sounds like it is working ok for you)

projectgus commented

2026-06-10 19:32:32 -05:00

(Migrated from github.com)

Thanks @kilograham!

it sounds like it is working ok for you

It is, although MicroPython relies on a pretty tiny subset of libc support. (In particular, no stdio - and I seem to recall there are some big differences in stdio buffering on newlib-nano).

Thanks @kilograham! > it sounds like it is working ok for you It is, although MicroPython relies on a pretty tiny subset of libc support. (In particular, no stdio - and I seem to recall there are some big differences in stdio buffering on newlib-nano).

kilograham commented

2026-06-17 16:25:38 -05:00

(Migrated from github.com)

note, i tried this, and I notice that newlib-nano has super slow variants of memcpy/memset/strlen, so we should probably at least override those again in this case on RP2350

Those were the only space savings i saw on kitchen_sink. i'll play around more when i come back to this, but not going to drop any support in for 2.2.1

note, i tried this, and I notice that newlib-nano has super slow variants of memcpy/memset/strlen, so we should probably at least override those again in this case on RP2350 Those were the only space savings i saw on kitchen_sink. i'll play around more when i come back to this, but not going to drop any support in for 2.2.1