[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |