[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@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.)

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?

Ian.



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.