Re: Build problems with xen 4.7

[M A Young <m.a.young@durham.ac.uk>]

On Tue, 7 Jun 2016, Jan Beulich wrote:

> >>> On 07.06.16 at 12:35, <dunlapg@umich.edu> wrote:
> > On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> >> --- xen-4.7.0/config/StdGNU.mk.orig     2016-04-15 22:56:52.191227591 +0100
> >> +++ xen-4.7.0/config/StdGNU.mk  2016-04-15 23:01:40.978829756 +0100
> >> @@ -37,6 +37,12 @@
> >>
> >>  ifneq ($(debug),y)
> >>  CFLAGS += -O2 -fomit-frame-pointer -fno-tree-coalesce-vars
> >> +ifeq ($(XEN_TARGET_ARCH),x86_64)
> >> +#might be cross-compiling so strip out possible x86_32 options
> >> +CFLAGS += $(shell echo $(CFLAGS_EXTRA) | sed -e 's/-m32//g' -e 's/-march=i686//g' -e 's/-mtune=atom//g')
> >> +else
> >> +CFLAGS += $(CFLAGS_EXTRA)
> >> +endif
> > 
> > Why the if?  Under what circumstances is it actually appropriate to
> > pass in those kinds of flags to the Xen build system?
> 
> -m options in general are machine specific, so any of those three
> may have a meaning on e.g. ARM (I agree that at least for the
> latter two this is rather unlikely, but anyway). Otoh I can't really
> see the purpose of this stripping: If we're cross compiling, the
> extra flags should be set accordingly by the invoking environment.
> 
> What I find odd is that this gets put inside a debug=n only section.

I happened to put it there because I was editing the same section to trace 
a gcc bug (note the addition of -fno-tree-coalesce-vars in the line above 
for that patch). It can go elsewhere, though note that the CFLAGS from the 
OS may contain the -O2 option which might interfere with the debug 
options.

	Michael Young

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