Re: stdbool.h -nostdinc XSA-55 trouble

["Egger, Christoph" <chegger@amazon.de>]

On 08.08.13 17:23, 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
>>>>
>>>> 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?

NetBSD does not use the compiler provided interface
and this is why gcc -print-search-dirs | grep install
is empty and stubdom does not build.

Adding Joerg Sonnenberger to CC. He can explain the details
why NetBSD does not use compiler provided interfaces.

Christoph