From: Patrick Welche <prlw1@cam.ac.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: stdbool.h -nostdinc XSA-55 trouble
Date: Thu, 8 Aug 2013 16:39:09 +0100 [thread overview]
Message-ID: <20130808153909.GC870@quark> (raw)
In-Reply-To: <1375975437.14651.7.camel@kazak.uk.xensource.com>
On Thu, Aug 08, 2013 at 04:23:57PM +0100, Ian Campbell wrote:
> On Thu, 2013-08-08 at 16:18 +0100, Patrick Welche wrote:
> > On Thu, Aug 08, 2013 at 02:11:16PM +0100, Jan Beulich wrote:
> > > >>> On 08.08.13 at 13:49, Patrick Welche <prlw1@cam.ac.uk> wrote:
> > > > I hope that this is the right list for compilation issues.
> > > >
> > > > When building libelf-tools.c with gcc 4.5.4 on NetBSD-current/amd64:
> > > >
> > > > In file included from libelf-private.h:25:0,
> > > > from libelf-tools.c:19:
> > > > /usr/src/local/xen/xen/include/xen/libelf.h:32:21: fatal error: stdbool.h:
> > > > No such file or directory
[...]
> > > No mystery, but also not immediately obvious: -iwithprefix adds
> > > the compiler's include directory to the end of the include search
> > > paths, thus allowing stdbool.h and stdarg.h to be found. For
> > > stdarg.h (which you ought to have the same problem with in
> > > libelf/) xen/stdarg.h already has special treatment for
> > > __OpenBSD__ and __NetBSD__ (i.e. avoiding similar problems
> > > for all the cases where xen/stdarg.h is used instead of plain
> > > stdarg.h).
> > >
> > > Whether that's not the case on NetBSD, or whether that directory
> > > simply doesn't exist or is empty you'd need to find out on your
> > > installation.
> >
> > So, in xen/arch/x86/Rules.mk, there is "-iwithprefix include",
> > which means add "include" to the end of the directory defined
> > by the "-iprefix DIR" option. I just looked on an ubuntu 10 box,
> > and gcc -v lists "--prefix=/usr" which seems to be used as the
> > default value of -iprefix. The gcc compiler on the NetBSD box
> > doesn't list --prefix as one of its configure options, so
> > I don't know what directory is used as the default prefix. ""?
After Ian's comment below - that bit of "--prefix=/usr" theory is
wrong as on the ubuntu box stdbool.h is indeed under /usr/lib/gcc...
and the default prefix is where gcc "staging files" are kept.
[...]
> > (/usr/include/stdbool.h is what we are aiming for.)
>
> At least on Debian we are actually aiming
> for /usr/lib/gcc/x86_64-linux-gnu/X.Y/include/stdbool.h
>
> I don't have /usr/include/stdbool.h. This makes sense since stdbool is,
> AIUI, a compiler provided interface, not a libc one.
>
> Perhaps this is a difference between Linux and BSD?
So it seems. According to stdbool(3) on the NetBSD box
STANDARDS
The <stdbool.h> header conforms to ISO/IEC 9899:1999 (``ISO C99'') and
IEEE Std 1003.1-2001 (``POSIX.1'').
HISTORY
The <stdbool.h> header was first introduced in NetBSD 1.6.
and ominously
The ability to undefine and redefine the macros bool, true, and false is
an obsolescent feature that may be withdrawn in a future version of a
standard.
Does this have implications for the orginal XSA-55?
Cheers,
Patrick
next prev parent reply other threads:[~2013-08-08 15:39 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-08 11:49 stdbool.h -nostdinc XSA-55 trouble Patrick Welche
2013-08-08 13:11 ` Jan Beulich
2013-08-08 15:18 ` Patrick Welche
2013-08-08 15:23 ` Ian Campbell
2013-08-08 15:39 ` Patrick Welche [this message]
2013-08-14 9:36 ` Egger, Christoph
2013-08-08 15:30 ` Jan Beulich
2013-08-08 15:47 ` Patrick Welche
2013-08-08 16:12 ` Ian Campbell
2013-08-08 17:26 ` Patrick Welche
2013-08-08 19:05 ` Andrew Cooper
2013-08-08 19:24 ` Ian Campbell
2013-08-08 19:52 ` Andrew Cooper
2013-08-09 7:50 ` Jan Beulich
2013-08-09 8:11 ` Patrick Welche
2013-08-09 8:16 ` Jan Beulich
2013-08-09 8:32 ` Patrick Welche
2013-08-09 8:33 ` Patrick Welche
2013-08-09 8:40 ` Jan Beulich
2013-08-09 15:13 ` Tim Deegan
2013-08-11 15:21 ` Patrick Welche
2013-08-09 6:44 ` Jan Beulich
2013-08-09 7:55 ` Patrick Welche
2013-08-11 16:41 ` Patrick Welche
2013-08-12 7:31 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130808153909.GC870@quark \
--to=prlw1@cam.ac.uk \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).