Picolibc: C library designed for embedded 32- and 64- bit systems

Not bought by Musk yet :)

Seriously though: Making your fork "unhooked" from its parent is not very difficult, it only takes one support request and they usually get back to you within the week.

Independently of that, yes, search should find forks too.

https://github.com/search?q=picolibc&p=1

For me it was discoverable via the fourth and tenth results.

       picolibc
  
    1. 005 https://github.com/mtottenh/picolibc
    2. 005 https://github.com/litex-hub/pythondata-software-picolibc
    3. 005 https://github.com/AshlingMicrosystems/picolibc
    4. 005 https://github.com/ft/zephyr-picolibc
    5. 005 https://github.com/keith-packard/picolibc-ci
    6. 005 https://github.com/modm-ext/picolibc-partial
    7. 005 https://github.com/philpem/picolibc-docker-arm
    8. 005 https://github.com/antmicro/pythondata-software-picolibc
    9. 005 https://github.com/likewise/riscv-picolibc-docker
   10. 005 https://github.com/picolibc/pico-hello
   11. 005 https://github.com/libhal/gcc-arm-none-eabi-picolibc
   12. 005 https://github.com/keith-packard/simple-mps
   13. 005 https://github.com/picolibc/simple-mps
   14. 005 https://github.com/swiftgeek/stm32f103-demo

I search Github from the command line, with no Javascript or cookies. To understand relationships between projects that are returned as results, I always go up a level to the user pages from the project pages, e.g., I looked at https://github.com/ft?tab=repositories&type=source and https://github.com/picolisp?tab=repositories&type=source

The biggest thing for me is the meson build system. newlib uses autoconf-generated files checked into the build tree, with several different versions of autoconf used depending on directory. So you have to keep several versions of autoconf around if you want to add e.g. another source file without churning the generated files.

iirc Keith talked about other library comparisons in his LCA talk about picolibc: https://youtu.be/SC6aBezNFFQ

It's for baremetal, and works on much smaller microcontrollers. It also seems to carry its own processor init code which other libc doesn't carry.

>> Keith Packard

> Now, that is a name.

A name and a whole lot of history

> Can this library be used as a replacement for glibc ?

glibc doesn't generally do well on "smaller embedded systems with limited ROM and RAM", but ymmv, depends on what "small" means for you

> Can this library be used as a replacement for glibc ?

No. This is designed to run on bare-metal. It's rather a replacement for newlib.

Your guess is as good as mine. I assume it makes sense for running the test suite quickly before running it slowly, and for use with 64-bit baremetal raspberry pi, Atom, and their ilk.

Some of the author's blog posts may answer that:

https://keithp.com/blogs/embedded-arm-libc/ https://keithp.com/blogs/picolibc/ https://keithp.com/blogs/tags/picolibc/

IIRC they do a lot of stuff with amateur rocketry, so it might related to that.

Only in a very special cases.

I'm writing embedded bare-metal 64-bit arm code at work right now. That is because the product needs less than 300ms boot times from power on and needs to be fast enough to do image compression (AVIF) in a reasonable time. Just using Linux and suspend would eat too much battery from the power budget. It has to have 1 year of battery life like previous generation of that same product.

i.MX RT1170 with its 1Ghz 32Bit Cortex-M7 core was not fast enough so we had to jump up to much faster 64bit Cortex-A53 core.

It's easy to avoid the functions with global state and Newlib can be built to minimize or eliminate their RAM consumption.

Greenspun's rule also applies to libc's. I've seen far more bugs introduced by bad "bare metal" libc reimplementations than I've seen difficulties introduced by just using using a real libc.

I'm not sure what your alternative is to stateful runtimes and I'm very curious what such a thing would look like beyond the reentrant APIs already in most libcs. Even Go and Haskell use stateful runtimes above the OS e.g. allocators/GC.

All parts of libc are not created equal. Some bits have hard dependencies on OS functionality that would make it a no-go in embedded. Other pieces, like string functions, are 100% CPU with no syscalls -- no reason not to have a good, optimized memcpy on embedded.