This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

_WANT_REENT_SMALL not defined for Newlib in Arm GNU Toolchain 11.2

It appears that Newlib in the Arm GNU Toolchain Version 11.2-2022.02 is not configured with --enable-newlib-reent-small.  I installed gcc-arm-11.2-2022.02-mingw-w64-i686-arm-none-eabi and built one of my embedded applications.  The linker failed due to a RAM overflow.  I figured out that _WANT_REENT_SMALL in newlib.h is not defined.  Moreover, Newlib in this toolchain is configured quite differently than the Newlib in the previous toolchain.

Are there plans to have a GNU Toolchain 11.2 with Newlib built with --enable-newlib-reent-small?

Parents
  • I created an account to post about this exact issue! I found that the newlib.h for the nano variant of the build is missing from the release package. This header is normally located at arm-none-eabi/include/newlib-nano, but that folder does not exist in the 11.2 release. However, nano.specs is still attempting to add it to the include path via the -isystem flag, which will not work because the folder is missing, and the result is that the newlib.h from the top-level directory, which is for the non-nano variant, is included instead.

    This issue will silently cause binary incompatibility between libc_nano.a and code compiled with nano.specs. I hope the release can be fixed soon, since I expect this issue will cause quite a few problems for downstream users.

Reply
  • I created an account to post about this exact issue! I found that the newlib.h for the nano variant of the build is missing from the release package. This header is normally located at arm-none-eabi/include/newlib-nano, but that folder does not exist in the 11.2 release. However, nano.specs is still attempting to add it to the include path via the -isystem flag, which will not work because the folder is missing, and the result is that the newlib.h from the top-level directory, which is for the non-nano variant, is included instead.

    This issue will silently cause binary incompatibility between libc_nano.a and code compiled with nano.specs. I hope the release can be fixed soon, since I expect this issue will cause quite a few problems for downstream users.

Children