Re: Newlib nano

["Bin.Cheng" <amker dot cheng at gmail dot com>]

On Thu, Jan 29, 2015 at 7:26 PM, lange@chello.at <lange@chello.at> wrote:
> Hello,
>
> We are using newlib at work, and are using different CPUs. We have one Arm9 with
> lotsa RAM and some Cortex M3/4 with rather paltry amounts of RAM.
> Im currently trying to fit a toolchain to serve both of them and thus want the
> nano-variants optimized for space.
>
> The issue I have is that some options affect the standard headers, notably
> _REENT_GLOBAL_ATEXIT and _WANT_REENT_SMALL. Since there is only one Header for
> both variants, this can result in problems if the reent struct is different than
> the linked library.


Hi lange,
Yes, we once had that problem when developing Nano in our toolchain
release "GNU Tools for ARM Embedded Processors".  In that we compiled
two versions of Newlib (one for size, the other with relatively full
features).  Back at that time we just changed implementation and made
sure that two version of libraries having identical headers.  It's
possible for us because we only use _WANT_REENT_SMALL for both
versions of libraries.


>
> 1) Is there some guide on which switches are allowed to differ? I only did some
Unfortunately, there isn't.
> grep -R <Macro> to see if its used outside of newlib.h and found the two above
> so far.
> Atleast for the board support you would need to have the correct newlib.h
> available.
I suspect the newlib.h is the only header file that matters, so
probably they are the only two options as you grepped.
>
> 2) I think about providing both newlib.h files (renamed) and defining a macro
> via the specs file to pick the right one via a stub. Im completely unused to
> specs files so I would be gratefull if someone could comment if thats a good
> solution.
It seems possible by using %p/%P (or some others) in specs file, but I
might misunderstand the meaning since I never touched that.

Thanks,
bin
>
> Kind Regards,
> Norbert Lange