[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |