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

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



On 6/7/16 6:42 AM, M A Young 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.
> 
>       Michael Young
> 

I have to say looking at the change and looking at the reason there
appears to be something very wrong with this. If you cross compile you
shouldn't have to strip out your BUILD_ARCH's CFLAGS from your
TARGET_ARCH's CFLAGS. It seems like somewhere those are getting crossed
together and that needs to be fixed rather than patching Xen.

If you think about it from x86 cross compiling for arm then this change
doesn't make sense. e.g. We don't have to strip out x86 CFLAGS in Xen
when we're building for arm.

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
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®.