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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.08.13 at 17:18, Patrick Welche <prlw1@xxxxxxxxx> 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. ""?

No, according to my checking, the --prefix configure option
listed does not correlate with the directory where the header
is found.

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

No, just go check adding -v to the compiler options. For me, the
directory is underneath where the gcc binaries (cc1 et al) are.

And we definitely don't want to have /usr/include or some such in
our include path.

Jan


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