Why don't embedded projects use glibc?

glibc (GNU C library) is the standard libc on desktop Linux. It's huge — a hello-world program statically linked against glibc is 100+ KB minimum. It assumes a full POSIX environment: filesystems, processes, dynamic linking, threads, locales, internationalization. None of that exists on bare-metal MCUs.

Embedded targets use one of three smaller alternatives:

• newlib — ~25-40 KB hello-world. The default in arm-none-eabi-gcc. Reasonably full-featured.
• newlib-nano — ~5-10 KB hello-world. A stripped-down newlib variant: smaller printf (no float by default), simpler malloc, less locale support. Most embedded projects use this. Switched in via --specs=nano.specs.
• picolibc — ~3-8 KB hello-world. A modern fork; even smaller, more modular, doesn't ship default syscall stubs (you provide them).

For embedded Linux systems (e.g., Yocto-built distros on a Cortex-A), glibc is fine because the OS provides the runtime environment. There you might also see musl as an alternative — smaller than glibc, MIT-licensed, more standards-compliant.

The interview-relevant lesson: don't confuse bare-metal embedded with embedded Linux. The libc choice is one of the clearest indicators of which environment you're in. If someone says "I just call printf and floats work" on a 256 KB Cortex-M, they probably haven't measured Flash usage and are unaware they've doubled their binary size by pulling in newlib's IEEE 754 conversion routines.