Re: [Xen-devel] stdbool.h -nostdinc XSA-55 trouble

[Patrick Welche <prlw1@xxxxxxxxx>]

On Thu, Aug 08, 2013 at 02:11:16PM +0100, Jan Beulich wrote:
> >>> On 08.08.13 at 13:49, Patrick Welche <prlw1@xxxxxxxxx> 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
> > 
> > I ran into this problem when trying to apply XSA-55 to xen 4.2.2, but
> > just reproduced it in -head.
> > 
> > I think this issue stems from a combination of commit 7a549a6aa
> > ...
> >     libelf: use C99 bool for booleans
> > ...
> >     In this patch we change all the booleans in libelf to C99 bool,
> >     from <stdbool.h>.
> > 
> > and
> > 
> > xen/arch/x86/Rules.mk:
> > ifneq ($(XEN_OS),SunOS)
> > CFLAGS-$(gcc) += -nostdinc
> > endif
> > 
> > If I comment out the -nostdinc in Rules.mk, I get a successful "make xen".
> 
> So perhaps NetBSD then needs a similar override as Solaris. But
> suppressing -nostdinc is a bad idea in general, and I wonder why
> this sits in a arch specific makefile instead of in xen/Rules.mk, as
> this ought to always be in effect for the hypervisor builds.

Indeed: I wondered whether you were all working on the arm port so didn't
see it ;-)

> > (One mystery: why aren't you all seeing this?)
> 
> 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. ""?

diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 0a9d68d..223aa1c 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -26,7 +26,7 @@ CFLAGS-$(gcc) += -nostdinc
 endif
 
 CFLAGS += -fno-builtin -fno-common -Wredundant-decls
-CFLAGS += -iwithprefix include -Werror -Wno-pointer-arith -pipe
+CFLAGS += -iprefix /usr/ -iwithprefix include -Werror -Wno-pointer-arith -pipe
 CFLAGS += -I$(BASEDIR)/include 
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default

also got me a successful build.
(/usr/include/stdbool.h is what we are aiming for.)

But is this all worthwhile? We are using the standard header file
stdbool.h, telling the preprocessor not to look in the standard
system directories with -nostdinc, and then telling the preprocessor,
via -iwithprefix, to look in /usr/include, which is the main standard
system directory, anyway.

Cheers,

Patrick

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel