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

[George Dunlap <dunlapg@xxxxxxxxx>]

On Tue, Jun 7, 2016 at 11:42 AM, M A Young <m.a.young@xxxxxxxxxxxx> wrote:
> On Tue, 7 Jun 2016, George Dunlap 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?
>
> That may not be needed in general. It is something I added for Fedora as I
> am cross-compiling the hypervisor as x86_64 to put in the i686 package
> because ix86 hypervisors are no longer supported.

It could be argued that the person setting CFLAGS_EXTRA should remove
those before calling 'make xen' when cross-compiling.  Setting
CFLAGS_EXTRA=-m32 make XEN_TARGET_ARCH=x86_64 doesn't really make much
sense. :-)

At the moment, for example, I've got to unset all additional CFLAGS
before calling "make stubdom" or the resulting pvgrub images crash on
boot.  To be consistent we should try to either 1) Make it the
caller's job to make sure not to pass in inappropriate arguments, or
2) make it Xen's job to filter out all inappropriate options.

I'm inclined to go with #1, at least to begin with, for simplicity.
What do you think?

 -George

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