| Message ID | 1392074974-1488-1-git-send-email-julien.grall@linaro.org |
|---|---|
| State | Rejected |
| Headers | show |
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.
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.
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!
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__ */ >
(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,
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
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(-)