These are the steps to build newlib used in ESP32 ROM and ESP-IDF

newlib-esp32-configure.sh

git clone https://github.com/espressif/newlib-esp32.git &&
  cd newlib-esp32 && \
	./configure \
		--with-newlib \
		--enable-multilib \
		--disable-newlib-io-c99-formats \
		--disable-newlib-supplied-syscalls  \
		--enable-newlib-nano-formatted-io \
		--enable-newlib-reent-small \
		--enable-target-optspace \
		--program-transform-name="s&^&xtensa-esp32-elf-&" \
		--disable-option-checking \
		--with-target-subdir=xtensa-esp32-elf \
		--target=xtensa-esp32-elf \
		--prefix=$(TARGET_DIR) \
	&& CROSS_CFLAGS="-DSIGNAL_PROVIDED -DABORT_PROVIDED -DMALLOC_PROVIDED" make all install

How are the xtensa-overlays incorporated into the build process. Are they already included in the newlib esp32 fork?

Wouldn't it be easy to build a docker container and even integrate it into a CI, e.g. with GitHub actions generally available now? Would you accept PRs to the newlib esp32 fork?

Hi @jdoubleu,

When building the cross-compiler toolchains, newlib, GCC and so on are built using Crosstool-NG project: https://github.com/espressif/crosstool-NG. Crosstool-NG knows how to extract the chip-specific overlay from xtensa-overlays and copy files from the overlay into the correct locations.
We do have CI set up in crosstool-NG repository, that's how release artifacts are produced — just not in Github Actions but in (internal) Gitlab: https://github.com/espressif/crosstool-NG/blob/esp-1.24.x/.gitlab-ci.yml.

This snippet was written (i think) as a reference about how newlib was built for inclusion into ESP32 ROM code. I don't think it's useful as a Github Action, since it's essentially a one-off task — once the ROM code for the chip is created, it's not changed anymore.

If you have some other use case where you see this or a similar script useful, please open an issue in https://github.com/espressif/newlib-esp32 project.