We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello,
This exact question was asked before in https://community.arm.com/support-forums/f/compilers-and-libraries-forum/53452/include-limits-h-on-arm-gnu-toolchain-11-3-rel1-x86_64-arm-none-eabi-is-this-a-bug. But as a summary, due to a bug, it is not possible to include arm-none-eabi/include/limits.h, as ./lib/gcc/arm-none-eabi/12.2.1/include-fixed/limits.h is prefered by the preprocessor. This is bad because lib/gcc/arm-none-eabi/12.2.1/include-fixed/limits.h is obviously not meant to be included directly, and arm-none-eabi/include/limits.h will even include it using include-next. The preprocessor will however search trough lib/gcc/arm-none-eabi/12.2.1/include-fixed before arm-none-eabi/include, so that the only fix is to change the toolchain by copying or moving arm-none-eabi/include/limits.h to lib/gcc/arm-none-eabi/12.2.1/include (works because that is the first path the preprocessor will check)
To me this is a problem because the code I am using checks for newlib, and arm-none-eabi/include/limits.h will pull in the correct defines/headers so that newlib is correctly recognized, while lib/gcc/arm-none-eabi/12.2.1/include-fixed/limits.h will not pull in those defines.
The linked post seems to already explain how to fix this issue. Other arm-none-eabi crosscompiler packages (such as the Arch Linux one, https://gitlab.archlinux.org/archlinux/packaging/packages/arm-none-eabi-gcc/-/blob/main/PKGBUILD) also dont suffer from this issue, so it seems to be a configuration issue on the side of ARM.