[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Build problems with xen 4.7



On Tue, 7 Jun 2016, Jan Beulich wrote:

> >>> On 07.06.16 at 12:35, <dunlapg@xxxxxxxxx> wrote:
> > On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk
> > <konrad.wilk@xxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.