[PATCH] Automated the generation of the __NEWLIB__, __NEWLIB_MINOR__ and __NEWLIB_PATCHLEVEL__ macros.

Jeff Johnston jjohnstn@redhat.com
Fri Jan 29 15:11:00 GMT 2016


----- Original Message -----
> On Thu, Jan 28, 2016 at 08:27:06AM -0500, Jeff Johnston wrote:
> > I am in Belgium this week.  Most of the patch is fine, however, there is a
> > problem caused
> > because <sys/features.h> doesn't include <newlib.h> and existing code could
> > be expecting
> > <sys/features.h> to bring in the definition of the macros.
> 
> Thanks Jeff, you're right. I wrongly assumed that consumers will
> _always_ include the generated newlib.h.
> 
> Even though newlib.h gets included by _ansi.h, which gets included
> almost everywhere, it is _not_ included from all the files that
> libc/include/sys/features.h is being included from. If a consumer of
> newlib includes any of the following, libc/include/sys/features.h gets
> included, but not newlib.h:
> 
> libc/include/complex.h
> libc/include/fnmatch.h
> libc/include/glob.h
> libc/include/machine/_default_types.h
> libc/include/machine/endian.h
> libc/include/machine/_types.h
> libc/include/regex.h
> libc/include/stdint.h
> libc/include/sys/cdefs.h
> libc/include/sys/config.h
> libc/include/sys/features.h
> libc/include/sys/_intsup.h
> libc/include/sys/param.h
> libc/include/sys/queue.h
> libc/include/sys/select.h
> libc/include/sys/_stdint.h
> libc/include/sys/timespec.h
> libc/include/sys/tree.h
> 
> I can easily adapt the patch, but of course there's at least 3 ways to do
> this (note: all solutions require the re-definition guarding,
> mentioned above):
> 
> 1. Simply leave libc/include/sys/features.h as is, and live with the
> burden of manually updating the version macros in it, every time the
> version changes.
> #ifndef __NEWLIB_H__
>   #define __NEWLIB__ 2
>   #define __NEWLIB_MINOR__ 2
>   #define __NEWLIB_PATCHLEVEL__ 0
> #endif
> 
> 2. We generate a newlib_version.h at the same level as newlib.h
> is, and include newlib_version.h in both newlib.h and
> libc/include/sys/features.h.
> 

This idea could be modified to do something like glibc does for bringing in particular macros
from a header file (e.g. __need_size_t to bring in just size_t from stddef.h).  Thus, you
set __need_version_macros and include newlib.h in <sys/features.h> and modify newlib.h.in
accordingly.  This restores the current behaviour.  What do you think?

> 3. Remove the existing 2 definitions from libc/include/sys/features.h
> and include newlib.h in the 18 header files, mentioned at the start of
> this email.
> 
> Although the 2nd and 3rd solution requires a bit more work, it frees the
> maintainer(s) of newlib from the burden to update the version in 2
> different places, every time the version changes.
> 
> Please let me know which one you'd prefer. Other suggestions are also
> welcome.
> 
> BTW, I'm voting for solution 3.
> 
> --
> Pieter du Preez
> 



More information about the Newlib mailing list