• State Accepted Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 22 subscribers
  • Views 2596 views
  • Users 0 members are here
2025 survey

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.

Options
Related
How was your experience today?
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

Dana N

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?

  • 0

    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.

  • 0 Arm Employee Badge in reply to Aaron O

    A fix for this is being worked on, and should be available in a future release.

  • +1 Arm Employee Badge
    Hi Dana,

    I've done digging in our build scripts and as far as I can tell we've never had `--enable-newlib-reent-small` enabled for base Newlib, but we have always had it enabled for Newlib-Nano, which is also affected by the issue Aaron mentioned below and we are working on a fix for. When that is fixed, you could potentially use Newlib-Nano? In the meantime, I'll raise a query internally about enabling for base Newlib as well (and if there's any compelling reason why we don't have it enabled already)

    You are right the differences between the 11.2 Newlib and the previous releases. I have identified:

    ** --enable-newlib-retargetable-locking
    ** --enable-newlib-mb
    ** --enable-newlib-register-fini

    And we are working on reverting these to what they were for the previous GNU-RM releases. If you come across anything further, do let us know!
  • 0

    Stam,

    Sorry about that.  I should've been more precise.  I was referring to newlib-nano, not newlib.  I noticed that _WANT_REENT_SMALL wasn't being defined in newlib.h for newlib-nano, and this was causing a large runtime RAM footprint.

    I have no need for newlib, but still have a need for newlib-nano.

    Thank you.

  • 0 Arm Employee Badge in reply to Dana N

    Ahh thanks for the clarification, this makes more sense now! In that case, the fix we have in progress to bring back the newlib-nano-specific include/newlib-nano/newlib.h should be good for you in the upcoming release :)

  • 0 in reply to Stam Markianos-Wright

    How do we specify to use newlib-nano instead of newlib?

  • 0 Arm Employee Badge in reply to ScottB

    When invoking the compiler, if you use the option --specs=nano.specs, then this specifies the use of newlib-nano instead of newlib. 

    However, the issue described here is affecting the current release, and a fix for that is being worked on.