[Xen-devel] xen: Don't use -nostdinc flags with CLANG

Message ID 1392074974-1488-1-git-send-email-julien.grall@linaro.org
State Rejected
Headers show

Commit Message

Julien Grall Feb. 10, 2014, 11:29 p.m.
Commit 06a9c7e "xen: move -nostdinc into common Rules.mk." breaks
compilation with clang:

In file included from sched_sedf.c:8:
In file included from /home/julieng/works/xen/xen/include/xen/lib.h:5:
/home/julieng/works/xen/xen/include/xen/stdarg.h:20:12: error: 'stdarg.h' file
not found with <angled> include; use "quotes" instead
           ^~~~~~~~~~
           "stdarg.h"
In file included from sched_sedf.c:8:
/home/julieng/works/xen/xen/include/xen/lib.h:101:63: error: unknown type name 'va_list'
extern int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
                                                              ^
/home/julieng/works/xen/xen/include/xen/lib.h:105:64: error: unknown type name 'va_list'
extern int vscnprintf(char *buf, size_t size, const char *fmt, va_list args)

I have the same errors on different version of clang:
    - clang 3.0 on debian wheezy
    - clang 3.3 on Fedora 20
    - clang 3.5 build from trunk

Removing -nostdinc fix the build on clang.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/Rules.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Julien Grall Feb. 11, 2014, 12:30 p.m. | #1
On 11/02/14 08:53, Tim Deegan wrote:
> At 23:29 +0000 on 10 Feb (1392071374), Julien Grall wrote:
>> Commit 06a9c7e "xen: move -nostdinc into common Rules.mk." breaks
>> compilation with clang:
>>
>> In file included from sched_sedf.c:8:
>> In file included from /home/julieng/works/xen/xen/include/xen/lib.h:5:
>> /home/julieng/works/xen/xen/include/xen/stdarg.h:20:12: error: 'stdarg.h' file
>> not found with <angled> include; use "quotes" instead
>>             ^~~~~~~~~~
>>             "stdarg.h"
>
> Looks like on your system stdarg.h doesn't live in a compiler-specific
> path, like we have for the BSDs.  I think we should just go to using
> our own definitions for stdarg/stdbool everywhere; trying to chase the
> compiler-specific versions around is a PITA, and the pieces we
> actually need are trivial.

For BSDs, we are using our own stdargs/stdbool.  So we don't include the 
system <stdarg.h>.

Linux is using $(CC) -print-file-name=include to get the right path. It 
works with both gcc and clang on Linux distos, but not on FreeBSD.
Julien Grall Feb. 11, 2014, 12:36 p.m. | #2
On 11/02/14 12:35, Tim Deegan wrote:
> At 12:30 +0000 on 11 Feb (1392118227), Julien Grall wrote:
>>
>>
>> On 11/02/14 08:53, Tim Deegan wrote:
>>> At 23:29 +0000 on 10 Feb (1392071374), Julien Grall wrote:
>>>> Commit 06a9c7e "xen: move -nostdinc into common Rules.mk." breaks
>>>> compilation with clang:
>>>>
>>>> In file included from sched_sedf.c:8:
>>>> In file included from /home/julieng/works/xen/xen/include/xen/lib.h:5:
>>>> /home/julieng/works/xen/xen/include/xen/stdarg.h:20:12: error: 'stdarg.h' file
>>>> not found with <angled> include; use "quotes" instead
>>>>              ^~~~~~~~~~
>>>>              "stdarg.h"
>>>
>>> Looks like on your system stdarg.h doesn't live in a compiler-specific
>>> path, like we have for the BSDs.  I think we should just go to using
>>> our own definitions for stdarg/stdbool everywhere; trying to chase the
>>> compiler-specific versions around is a PITA, and the pieces we
>>> actually need are trivial.
>>
>> For BSDs, we are using our own stdargs/stdbool.  So we don't include the
>> system <stdarg.h>.
>>
>> Linux is using $(CC) -print-file-name=include to get the right path. It
>> works with both gcc and clang on Linux distos, but not on FreeBSD.
>
> Wait - is the error message you posted from clang on FreeBSD?
> That's surprising; on FreeBSD xen/stdarg.h shouldn't be trying to
> include <stdarg.h> at all.  Is __FreeBSD__ not being defined?


No it's from Linux (Debian Wheezy and Fedora). I just gave a try to the 
"-print-file-name" solution on FreeBSD.
Julien Grall Feb. 11, 2014, 1:20 p.m. | #3
On 11/02/14 12:59, Tim Deegan wrote:
> Are you using a very old version of clang?  As 06a9c7e points out,
> our current runes didn't work before clang v3.0.

I'm using clang 3.5 (which have other issue to compile Xen), but I have 
also tried 3.0 and 3.3.

> If not, rather than chasing this around any further, I think we should
> abandon trying to use the compiler-provided headers even on linux.
> Does this patch fix your build issue?
>
> commit e7003f174e0df9192dde6fa8d33b0a20f99ce053
> Author: Tim Deegan <tim@xen.org>
> Date:   Tue Feb 11 12:44:09 2014 +0000
>
>      xen: stop trying to use the system <stdarg.h> and <stdbool.h>

With this patch, -iwithprefix include is not necessary now. I wondering 
if we can remove it from the command line.

>      We already have our own versions of the stdarg/stdbool definitions, for
>      systems where those headers are installed in /usr/include.
>
>      On linux, they're typically installed in compiler-specific paths, but
>      finding them has proved unreliable.  Drop that and use our own versions
>      everywhere.
>
>      Signed-off-by: Tim Deegan <tim@xen.org>

This patch is working fine to build xen clang 3.0, 3.3.
I have others issue to build with clang 3.5.

Tested-by: Julien Grall <julien.grall@linaro.org>

Thanks!
Julien Grall Feb. 11, 2014, 1:21 p.m. | #4
On 11/02/14 12:59, Tim Deegan wrote:
> At 12:36 +0000 on 11 Feb (1392118581), Julien Grall wrote:
>>
>>
>> On 11/02/14 12:35, Tim Deegan wrote:
>>> At 12:30 +0000 on 11 Feb (1392118227), Julien Grall wrote:
>>>>
>>>>
>>>> On 11/02/14 08:53, Tim Deegan wrote:
>>>>> At 23:29 +0000 on 10 Feb (1392071374), Julien Grall wrote:
>>>>>> Commit 06a9c7e "xen: move -nostdinc into common Rules.mk." breaks
>>>>>> compilation with clang:
>>>>>>
>>>>>> In file included from sched_sedf.c:8:
>>>>>> In file included from /home/julieng/works/xen/xen/include/xen/lib.h:5:
>>>>>> /home/julieng/works/xen/xen/include/xen/stdarg.h:20:12: error: 'stdarg.h' file
>>>>>> not found with <angled> include; use "quotes" instead
>>>>>>               ^~~~~~~~~~
>>>>>>               "stdarg.h"
>>>>>
>>>>> Looks like on your system stdarg.h doesn't live in a compiler-specific
>>>>> path, like we have for the BSDs.  I think we should just go to using
>>>>> our own definitions for stdarg/stdbool everywhere; trying to chase the
>>>>> compiler-specific versions around is a PITA, and the pieces we
>>>>> actually need are trivial.
>>>>
>>>> For BSDs, we are using our own stdargs/stdbool.  So we don't include the
>>>> system <stdarg.h>.
>>>>
>>>> Linux is using $(CC) -print-file-name=include to get the right path. It
>>>> works with both gcc and clang on Linux distos, but not on FreeBSD.
>>>
>>> Wait - is the error message you posted from clang on FreeBSD?
>>> That's surprising; on FreeBSD xen/stdarg.h shouldn't be trying to
>>> include <stdarg.h> at all.  Is __FreeBSD__ not being defined?
>>
>>
>> No it's from Linux (Debian Wheezy and Fedora). I just gave a try to the
>> "-print-file-name" solution on FreeBSD.
>
> Oh, OK.  Yeah, we knew that didn't work there, because on *BSD the
> compiler-specific headers like stdarg.h actually live in /usr/include
> and can themselves include other system headers.  That's why we have
> our own implementation of the bits we need, that we use on BSD.
>
> Are you using a very old version of clang?  As 06a9c7e points out,
> our current runes didn't work before clang v3.0.
>
> If not, rather than chasing this around any further, I think we should
> abandon trying to use the compiler-provided headers even on linux.
> Does this patch fix your build issue?
>
> commit e7003f174e0df9192dde6fa8d33b0a20f99ce053
> Author: Tim Deegan <tim@xen.org>
> Date:   Tue Feb 11 12:44:09 2014 +0000
>
>      xen: stop trying to use the system <stdarg.h> and <stdbool.h>
>
>      We already have our own versions of the stdarg/stdbool definitions, for
>      systems where those headers are installed in /usr/include.
>
>      On linux, they're typically installed in compiler-specific paths, but
>      finding them has proved unreliable.  Drop that and use our own versions
>      everywhere.
>
>      Signed-off-by: Tim Deegan <tim@xen.org>
>
> diff --git a/xen/include/xen/stdarg.h b/xen/include/xen/stdarg.h
> index d1b2540..0283f06 100644
> --- a/xen/include/xen/stdarg.h
> +++ b/xen/include/xen/stdarg.h
> @@ -1,23 +1,21 @@
>   #ifndef __XEN_STDARG_H__
>   #define __XEN_STDARG_H__
>
> -#if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__)
> -   typedef __builtin_va_list va_list;
> -#  ifdef __GNUC__
> -#    define __GNUC_PREREQ__(x, y)                                       \
> -        ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
> -         (__GNUC__ > (x)))
> -#  else
> -#    define __GNUC_PREREQ__(x, y)   0
> -#  endif
> -#  if !__GNUC_PREREQ__(4, 5)
> -#    define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
> -#  endif
> -#  define va_start(ap, last)    __builtin_va_start((ap), (last))
> -#  define va_end(ap)            __builtin_va_end(ap)
> -#  define va_arg                __builtin_va_arg
> +#ifdef __GNUC__
> +#  define __GNUC_PREREQ__(x, y)                                       \
> +      ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
> +       (__GNUC__ > (x)))
>   #else
> -#  include <stdarg.h>
> +#  define __GNUC_PREREQ__(x, y)   0
>   #endif
>
> +#if !__GNUC_PREREQ__(4, 5)
> +#  define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
> +#endif
> +
> +typedef __builtin_va_list va_list;
> +#define va_start(ap, last)    __builtin_va_start((ap), (last))
> +#define va_end(ap)            __builtin_va_end(ap)
> +#define va_arg                __builtin_va_arg
> +
>   #endif /* __XEN_STDARG_H__ */
> diff --git a/xen/include/xen/stdbool.h b/xen/include/xen/stdbool.h
> index f0faedf..b0947a6 100644
> --- a/xen/include/xen/stdbool.h
> +++ b/xen/include/xen/stdbool.h
> @@ -1,13 +1,9 @@
>   #ifndef __XEN_STDBOOL_H__
>   #define __XEN_STDBOOL_H__
>
> -#if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__)
> -#  define bool _Bool
> -#  define true 1
> -#  define false 0
> -#  define __bool_true_false_are_defined   1
> -#else
> -#  include <stdbool.h>
> -#endif
> +#define bool _Bool
> +#define true 1
> +#define false 0
> +#define __bool_true_false_are_defined   1
>
>   #endif /* __XEN_STDBOOL_H__ */
>
Julien Grall Feb. 11, 2014, 2:24 p.m. | #5
(Add George as release manager)

On 11/02/14 13:59, Tim Deegan wrote:
> At 13:20 +0000 on 11 Feb (1392121252), Julien Grall wrote:
>>
>>
>> On 11/02/14 12:59, Tim Deegan wrote:
>>> Are you using a very old version of clang?  As 06a9c7e points out,
>>> our current runes didn't work before clang v3.0.
>>
>> I'm using clang 3.5 (which have other issue to compile Xen), but I have
>> also tried 3.0 and 3.3.
>>
>>> If not, rather than chasing this around any further, I think we should
>>> abandon trying to use the compiler-provided headers even on linux.
>>> Does this patch fix your build issue?
>>>
>>> commit e7003f174e0df9192dde6fa8d33b0a20f99ce053
>>> Author: Tim Deegan <tim@xen.org>
>>> Date:   Tue Feb 11 12:44:09 2014 +0000
>>>
>>>       xen: stop trying to use the system <stdarg.h> and <stdbool.h>
>>
>> With this patch, -iwithprefix include is not necessary now. I wondering
>> if we can remove it from the command line.
>
> Yes, I think so.
>
>>>       We already have our own versions of the stdarg/stdbool definitions, for
>>>       systems where those headers are installed in /usr/include.
>>>
>>>       On linux, they're typically installed in compiler-specific paths, but
>>>       finding them has proved unreliable.  Drop that and use our own versions
>>>       everywhere.
>>>
>>>       Signed-off-by: Tim Deegan <tim@xen.org>
>>
>> This patch is working fine to build xen clang 3.0, 3.3.
>> I have others issue to build with clang 3.5.
>>
>> Tested-by: Julien Grall <julien.grall@linaro.org>
>
> Great!  Assuming you'll have a series of patches to fix the clang-3.5
> build, do you want to just take this into that series, and drop the
> -iwithprefix at the same time?

If it's possible I'd like this patch goes in Xen 4.4 to fix build with 
official version of clang (until 3.4).

Clang 3.5 is still under development, so I don't think it's important to 
have support for it in Xen 4.4.

Cheers,

Patch

diff --git a/xen/Rules.mk b/xen/Rules.mk
index df1428f..ed9b8d0 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -46,7 +46,8 @@  CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
 CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 # Solaris puts stdarg.h &c in the system include directory.
 ifneq ($(XEN_OS),SunOS)
-CFLAGS += -nostdinc -iwithprefix include
+CFLAGS-y        += -iwithprefix include
+CFLAGS-$(gcc)   += -nostdinc
 endif
 
 CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE