This is the mail archive of the
mailing list for the newlib project.
Re: _NEWLIB_VERSION exposure through sys/cdefs.h
- From: Craig Howland <howland at LGSInnovations dot com>
- To: Jeff Johnston <jjohnstn at redhat dot com>, Jonathan Roelofs <jonathan at codesourcery dot com>
- Cc: <newlib at sourceware dot org>, Corinna Vinschen <vinschen at redhat dot com>, Dan Albert <danalbert at google dot com>, JF Bastien <jfb at chromium dot org>
- Date: Wed, 17 Sep 2014 17:51:06 -0400
- Subject: Re: _NEWLIB_VERSION exposure through sys/cdefs.h
- Authentication-results: sourceware.org; auth=none
- References: <5419F88C dot 70905 at codesourcery dot com> <823190835 dot 50677807 dot 1410990469041 dot JavaMail dot zimbra at redhat dot com>
On 09/17/2014 05:47 PM, Jeff Johnston wrote:
newlib.h gets included for almost every (and maybe even all) of the include
files, as _ansi.h includes it. So you should be able to include just about
anything that you cared to and check for _NEWLIB_VERSION. So, for example,
----- Original Message -----
From: "Jonathan Roelofs" <firstname.lastname@example.org>
To: email@example.com, "Corinna Vinschen" <firstname.lastname@example.org>
Cc: "Dan Albert" <email@example.com>, "JF Bastien" <firstname.lastname@example.org>
Sent: Wednesday, September 17, 2014 5:09:32 PM
Subject: _NEWLIB_VERSION exposure through sys/cdefs.h
In libc++, we'd like to be able to tell when the underlying libc is Newlib.
the moment, that requires us to do things like this:
#if defined(__has_include) && __has_include(<newlib.h>)
The problem with that strategy is that it does not work when using gcc, as it
doesn't have __has_include support yet. It came up in discussion that
sys/cdefs.h might be the right place for that, as that's where glibc puts
Would there be an objection to #include <newlib.h> from sys/cdefs.h? Is
better way to detect Newlib that I've overlooked?
Corinna is on vacation until Oct 8th.
My version of glibc has __GLIBC__ defined in features.h which in glibc is
included by sys/cdefs.h.
I wouldn't have a problem with simply adding a __NEWLIB__ macro in newlib's
features.h. I also wouldn't have a real problem with including newlib.h from sys/cdefs.h
though I notice one of the newlib.h macros is missing an underscore and needs to be fixed.
A way of solving your problem now would be to look for:
that is set by <machine/_default_types.h> which is a newlib-specific header
that is included by sys/cdefs.h. I don't see any platform overriding sys/cdefs.h
except for x86-linux and it eventually includes <machine/_default_types.h> as
-- Jeff J.
works. (This is more clear than _MACHINE_DEFAULT_TYPE_H and saves needing to
add __NEWLIB__ as Jeff suggests. Although the latter is not a bad idea.)
CodeSourcery / Mentor Embedded