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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.