Build problems with xen 4.7

Build problems with xen 4.7

[M A Young]

When I try to build the current xen 4.7 master I get the following error

<command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
<command-line>:0:0: note: this is the location of the previous definition
cc1: all warnings being treated as errors

The problem seems to be that -D__OBJECT_FILE__= is set each time 
xen/Rules.mk is called, which happens more than once because of nested 
makes resulting in multiple diffent values for -D__OBJECT_FILE__=

	Michael Young

Re: Build problems with xen 4.7

[Jan Beulich]

>>> On 01.12.15 at 00:37, <m.a.young@durham.ac.uk> wrote:
> When I try to build the current xen 4.7 master I get the following error
> 
> <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> <command-line>:0:0: note: this is the location of the previous definition
> cc1: all warnings being treated as errors
> 
> The problem seems to be that -D__OBJECT_FILE__= is set each time 
> xen/Rules.mk is called, which happens more than once because of nested 
> makes resulting in multiple diffent values for -D__OBJECT_FILE__=

Considering you're the first one to have such a problem, I think the
precise compiler version you use matters here. Also the redundant
definitions shouldn't be different, and identical re-definition should
not yield a diagnostic. So I think there's a little more data you need
to supply in order to determine whether we need to adjust something.

Jan

Re: Build problems with xen 4.7

[Konrad Rzeszutek Wilk]

On December 1, 2015 8:19:32 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 01.12.15 at 00:37, <m.a.young@durham.ac.uk> wrote:
>> When I try to build the current xen 4.7 master I get the following
>error
>> 
>> <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
>> <command-line>:0:0: note: this is the location of the previous
>definition
>> cc1: all warnings being treated as errors
>> 
>> The problem seems to be that -D__OBJECT_FILE__= is set each time 
>> xen/Rules.mk is called, which happens more than once because of
>nested 
>> makes resulting in multiple diffent values for -D__OBJECT_FILE__=
>
>Considering you're the first one to have such a problem, I think the
>precise compiler version you use matters here. Also the redundant
>definitions shouldn't be different, and identical re-definition should
>not yield a diagnostic. So I think there's a little more data you need
>to supply in order to determine whether we need to adjust something.
>

Ccing Marcos who also saw this. Marcos do you remember the git commit that caused this?


Thanks!
>Jan
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/xen-devel

Re: Build problems with xen 4.7

[Marcos E. Matsunaga]

The commit that created this is :

9a6787cc3809c1e48e6fce22cacdd0def0cc2b92 x86/mm: build map_domain_gfn() 
just once

On 12/01/2015 09:36 AM, Konrad Rzeszutek Wilk wrote:
> On December 1, 2015 8:19:32 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 01.12.15 at 00:37, <m.a.young@durham.ac.uk> wrote:
>>> When I try to build the current xen 4.7 master I get the following
>> error
>>> <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
>>> <command-line>:0:0: note: this is the location of the previous
>> definition
>>> cc1: all warnings being treated as errors
>>>
>>> The problem seems to be that -D__OBJECT_FILE__= is set each time
>>> xen/Rules.mk is called, which happens more than once because of
>> nested
>>> makes resulting in multiple diffent values for -D__OBJECT_FILE__=
>> Considering you're the first one to have such a problem, I think the
>> precise compiler version you use matters here. Also the redundant
>> definitions shouldn't be different, and identical re-definition should
>> not yield a diagnostic. So I think there's a little more data you need
>> to supply in order to determine whether we need to adjust something.
>>
> Ccing Marcos who also saw this. Marcos do you remember the git commit that caused this?
>
>
> Thanks!
>> Jan
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>

-- 

Regards,

Marcos Eduardo Matsunaga

Oracle USA
Linux Engineering

“The statements and opinions expressed here are my own and do not
necessarily represent those of Oracle Corporation.”


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

Re: Build problems with xen 4.7

[Jan Beulich]

>>> On 01.12.15 at 15:36, <konrad.wilk@oracle.com> wrote:
> On December 1, 2015 8:19:32 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 01.12.15 at 00:37, <m.a.young@durham.ac.uk> wrote:
>>> When I try to build the current xen 4.7 master I get the following
>>error
>>> 
>>> <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
>>> <command-line>:0:0: note: this is the location of the previous
>>definition
>>> cc1: all warnings being treated as errors
>>> 
>>> The problem seems to be that -D__OBJECT_FILE__= is set each time 
>>> xen/Rules.mk is called, which happens more than once because of
>>nested 
>>> makes resulting in multiple diffent values for -D__OBJECT_FILE__=
>>
>>Considering you're the first one to have such a problem, I think the
>>precise compiler version you use matters here. Also the redundant
>>definitions shouldn't be different, and identical re-definition should
>>not yield a diagnostic. So I think there's a little more data you need
>>to supply in order to determine whether we need to adjust something.
>>
> 
> Ccing Marcos who also saw this. Marcos do you remember the git commit that 
> caused this?

There's no question about when this got introduced. What we need
to understand is why this is an issue only for very few people.

Jan

Re: Build problems with xen 4.7

[Konrad Rzeszutek Wilk]

On Tue, Dec 01, 2015 at 08:56:03AM -0700, Jan Beulich wrote:
> >>> On 01.12.15 at 15:36, <konrad.wilk@oracle.com> wrote:
> > On December 1, 2015 8:19:32 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>> On 01.12.15 at 00:37, <m.a.young@durham.ac.uk> wrote:
> >>> When I try to build the current xen 4.7 master I get the following
> >>error
> >>> 
> >>> <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> >>> <command-line>:0:0: note: this is the location of the previous
> >>definition
> >>> cc1: all warnings being treated as errors
> >>> 
> >>> The problem seems to be that -D__OBJECT_FILE__= is set each time 
> >>> xen/Rules.mk is called, which happens more than once because of
> >>nested 
> >>> makes resulting in multiple diffent values for -D__OBJECT_FILE__=
> >>
> >>Considering you're the first one to have such a problem, I think the
> >>precise compiler version you use matters here. Also the redundant
> >>definitions shouldn't be different, and identical re-definition should
> >>not yield a diagnostic. So I think there's a little more data you need
> >>to supply in order to determine whether we need to adjust something.
> >>
> > 
> > Ccing Marcos who also saw this. Marcos do you remember the git commit that 
> > caused this?
> 
> There's no question about when this got introduced. What we need
> to understand is why this is an issue only for very few people.

It is only an issue when doing rpmbuilds.

Not when doing the build outside of that.
> 
> Jan
> 

Re: Build problems with xen 4.7

[Jan Beulich]

>>> On 01.12.15 at 16:59, <konrad.wilk@oracle.com> wrote:
> On Tue, Dec 01, 2015 at 08:56:03AM -0700, Jan Beulich wrote:
>> >>> On 01.12.15 at 15:36, <konrad.wilk@oracle.com> wrote:
>> > On December 1, 2015 8:19:32 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>>> On 01.12.15 at 00:37, <m.a.young@durham.ac.uk> wrote:
>> >>> When I try to build the current xen 4.7 master I get the following
>> >>error
>> >>> 
>> >>> <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
>> >>> <command-line>:0:0: note: this is the location of the previous
>> >>definition
>> >>> cc1: all warnings being treated as errors
>> >>> 
>> >>> The problem seems to be that -D__OBJECT_FILE__= is set each time 
>> >>> xen/Rules.mk is called, which happens more than once because of
>> >>nested 
>> >>> makes resulting in multiple diffent values for -D__OBJECT_FILE__=
>> >>
>> >>Considering you're the first one to have such a problem, I think the
>> >>precise compiler version you use matters here. Also the redundant
>> >>definitions shouldn't be different, and identical re-definition should
>> >>not yield a diagnostic. So I think there's a little more data you need
>> >>to supply in order to determine whether we need to adjust something.
>> >>
>> > 
>> > Ccing Marcos who also saw this. Marcos do you remember the git commit that 
>> > caused this?
>> 
>> There's no question about when this got introduced. What we need
>> to understand is why this is an issue only for very few people.
> 
> It is only an issue when doing rpmbuilds.
> 
> Not when doing the build outside of that.

I.e. there must be something different in how make gets invoked or
the environment set up.

Jan

Re: Build problems with xen 4.7

[M A Young]

On Tue, 1 Dec 2015, Jan Beulich wrote:

> I.e. there must be something different in how make gets invoked or
> the environment set up.

It happens if CFLAGS is set to anything as a environment variable, eg.
export CFLAGS=" "
make dist-xen

	Michael Young

Re: Build problems with xen 4.7

[Olaf Hering]

On Tue, Dec 01, M A Young wrote:

> It happens if CFLAGS is set to anything as a environment variable, eg.
> export CFLAGS=" "
> make dist-xen

This never worked. I have this in xen.spec to workaround the way
%configure is implemented in rpm:

%configure <whatever>
unset CFLAGS
unset CXXFLAGS
unset FFLAGS
unset LDFLAGS
make <whatever>


Olaf

Re: Build problems with xen 4.7

[Andrew Cooper]

On 01/12/15 19:40, Olaf Hering wrote:
> On Tue, Dec 01, M A Young wrote:
>
>> It happens if CFLAGS is set to anything as a environment variable, eg.
>> export CFLAGS=" "
>> make dist-xen
> This never worked.

Works for me with CentOS-based RPM builds. 
(https://github.com/xenserver/xen-4.6.pg/blob/master/master/builder-makefiles.patch#L413
from XenServer)

>  I have this in xen.spec to workaround the way
> %configure is implemented in rpm:
>
> %configure <whatever>
> unset CFLAGS
> unset CXXFLAGS
> unset FFLAGS
> unset LDFLAGS
> make <whatever>

Requiring these unset's is definitely buggy behaviour, and should be fixing.

For me, the example given by Michael breaks even earlier.

andrewcoop@andrewcoop:/local/xen.git/xen$ CFLAGS=" " make -j4 -s
 __  __            _  _    __    _                  
 \ \/ /___ _ __   | || |  / /_  / |   _ __  _ __ ___
  \  // _ \ '_ \  | || |_| '_ \ | |__| '_ \| '__/ _ \
  /  \  __/ | | | |__   _| (_) || |__| |_) | | |  __/
 /_/\_\___|_| |_|    |_|(_)___(_)_|  | .__/|_|  \___|
                                     |_|            
Fields of 'compat_gnttab_cache_flush' not found in 'compat/grant_table.h'
Makefile:70: recipe for target 'compat/.xlat/grant_table.h' failed
make[2]: *** [compat/.xlat/grant_table.h] Error 1
make[2]: *** Waiting for unfinished jobs....
Fields of 'compat_mem_access_op' not found in 'compat/memory.h'
Makefile:70: recipe for target 'compat/.xlat/memory.h' failed
make[2]: *** [compat/.xlat/memory.h] Error 1
Makefile:104: recipe for target '/local/xen.git/xen/xen' failed
make[1]: *** [/local/xen.git/xen/xen] Error 2
Makefile:29: recipe for target 'build' failed
make: *** [build] Error 2


~Andrew

Re: Build problems with xen 4.7

[Jan Beulich]

>>> On 01.12.15 at 19:47, <m.a.young@durham.ac.uk> wrote:
> On Tue, 1 Dec 2015, Jan Beulich wrote:
>> I.e. there must be something different in how make gets invoked or
>> the environment set up.
> 
> It happens if CFLAGS is set to anything as a environment variable, eg.
> export CFLAGS=" "
> make dist-xen

Ugly, but I think it could be worked around (if we really want to
support CFLAGS coming in from the command line), along the lines
of

ABC_ORIG := $(ABC)
unexport ABC
MAKE := ABC=$(ABC_ORIG) $(MAKE)
ABC += xyz

all:
	@echo $@: 'ABC=$(ABC)' "ABC=$$ABC"
	$(MAKE) test

test:
	@echo $@: 'ABC=$(ABC)' "ABC=$$ABC"

Jan

Re: Build problems with xen 4.7

[Konrad Rzeszutek Wilk]

On Tue, Dec 01, 2015 at 10:59:41AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 01, 2015 at 08:56:03AM -0700, Jan Beulich wrote:
> > >>> On 01.12.15 at 15:36, <konrad.wilk@oracle.com> wrote:
> > > On December 1, 2015 8:19:32 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
> > >>>>> On 01.12.15 at 00:37, <m.a.young@durham.ac.uk> wrote:
> > >>> When I try to build the current xen 4.7 master I get the following
> > >>error
> > >>> 
> > >>> <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> > >>> <command-line>:0:0: note: this is the location of the previous
> > >>definition
> > >>> cc1: all warnings being treated as errors
> > >>> 
> > >>> The problem seems to be that -D__OBJECT_FILE__= is set each time 
> > >>> xen/Rules.mk is called, which happens more than once because of
> > >>nested 
> > >>> makes resulting in multiple diffent values for -D__OBJECT_FILE__=
> > >>
> > >>Considering you're the first one to have such a problem, I think the
> > >>precise compiler version you use matters here. Also the redundant
> > >>definitions shouldn't be different, and identical re-definition should
> > >>not yield a diagnostic. So I think there's a little more data you need
> > >>to supply in order to determine whether we need to adjust something.
> > >>
> > > 
> > > Ccing Marcos who also saw this. Marcos do you remember the git commit that 
> > > caused this?
> > 
> > There's no question about when this got introduced. What we need
> > to understand is why this is an issue only for very few people.
> 
> It is only an issue when doing rpmbuilds.
> 

Still an issue - with 4.7.0-rc1.

If I do:

$export CFLAGS=" "'
$make

I end up with:
gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ '-D__OBJECT_FILE__="/home/konrad/ssd/konrad/xen/xen/xen"' -Wa,--strip-local-absolute -fno-optimize-sibling-calls -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -fno-optimize-sibling-calls -I/home/konrad/ssd/konrad/xen/xen/include -I/home/konrad/ssd/konrad/xen/xen/include/asm-x86/mach-generic -I/home/konrad/ssd/konrad/xen/xen/include/asm-x86/mach-default '-D__OBJECT_LABEL__=omeonradsdonradenen$homeonradsdonradenenen' -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -mno-red-zone -mno-sse -fpic -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ '-D__OBJECT_FILE__="compat/callback.i"' -Wa,--strip-local-absolute -fno-optimize-sibling-calls -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -fno-optimize-sibling-calls -I/home/konrad/ssd/konrad/xen/xen/include -I/home/konrad/ssd/konrad/xen/xen/include/asm-x86/mach-generic -I/home/konrad/ssd/konrad/xen/xen/include/asm-x86/mach-default '-D__OBJECT_LABEL__=include$compat$callback.i' -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -mno-red-zone -mno-sse -fpic -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -include public/xen-compat.h -m32 -o compat/callback.i compat/callback.c
<command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
<command-line>:0:0: note: this is the location of the previous definition
<command-line>:0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
<command-line>:0:0: note: this is the location of the previous definition
cc1: all warnings being treated as errors
Makefile:62: recipe for target 'compat/callback.i' failed


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

Re: Build problems with xen 4.7

[Jan Beulich]

>>> On 13.05.16 at 15:49, <konrad.wilk@oracle.com> wrote:
> On Tue, Dec 01, 2015 at 10:59:41AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue, Dec 01, 2015 at 08:56:03AM -0700, Jan Beulich wrote:
>> > >>> On 01.12.15 at 15:36, <konrad.wilk@oracle.com> wrote:
>> > > On December 1, 2015 8:19:32 AM EST, Jan Beulich <JBeulich@suse.com> wrote:
>> > >>>>> On 01.12.15 at 00:37, <m.a.young@durham.ac.uk> wrote:
>> > >>> When I try to build the current xen 4.7 master I get the following
>> > >>error
>> > >>> 
>> > >>> <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
>> > >>> <command-line>:0:0: note: this is the location of the previous
>> > >>definition
>> > >>> cc1: all warnings being treated as errors
>> > >>> 
>> > >>> The problem seems to be that -D__OBJECT_FILE__= is set each time 
>> > >>> xen/Rules.mk is called, which happens more than once because of
>> > >>nested 
>> > >>> makes resulting in multiple diffent values for -D__OBJECT_FILE__=
>> > >>
>> > >>Considering you're the first one to have such a problem, I think the
>> > >>precise compiler version you use matters here. Also the redundant
>> > >>definitions shouldn't be different, and identical re-definition should
>> > >>not yield a diagnostic. So I think there's a little more data you need
>> > >>to supply in order to determine whether we need to adjust something.
>> > >>
>> > > 
>> > > Ccing Marcos who also saw this. Marcos do you remember the git commit that 
> 
>> > > caused this?
>> > 
>> > There's no question about when this got introduced. What we need
>> > to understand is why this is an issue only for very few people.
>> 
>> It is only an issue when doing rpmbuilds.
>> 
> 
> Still an issue - with 4.7.0-rc1.

And I don't recall anyone having contributed a fix/workaround.

> If I do:
> 
> $export CFLAGS=" "'
> $make
> 
> I end up with:
> gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 
>[...]
> <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> <command-line>:0:0: note: this is the location of the previous definition
> <command-line>:0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
> <command-line>:0:0: note: this is the location of the previous definition
> cc1: all warnings being treated as errors
> Makefile:62: recipe for target 'compat/callback.i' failed

My previous recommendation stands: Then just don't do this.

Jan


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

Re: Build problems with xen 4.7

[M A Young]

On Fri, 13 May 2016, Jan Beulich wrote:

> >>> On 13.05.16 at 15:49, <konrad.wilk@oracle.com> wrote:
> > ...
> > 
> > Still an issue - with 4.7.0-rc1.
> 
> And I don't recall anyone having contributed a fix/workaround.
> 
> > If I do:
> > 
> > $export CFLAGS=" "'
> > $make
> > 
> > I end up with:
> > gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 
> >[...]
> > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> > <command-line>:0:0: note: this is the location of the previous definition
> > <command-line>:0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
> > <command-line>:0:0: note: this is the location of the previous definition
> > cc1: all warnings being treated as errors
> > Makefile:62: recipe for target 'compat/callback.i' failed
> 
> My previous recommendation stands: Then just don't do this.

I hacked around it for my test builds (eg. see my test build at
https://copr.fedorainfracloud.org/coprs/myoung/xentest/build/204111/
) by not setting CFLAGS in the environment, but by instead adding the 
recommended Fedora RPM settings into config/StdGNU.mk via a different 
environment variable.

Another thing you might need to know if you are building xen on Fedora 24 
is that you need to add -fno-tree-coalesce-vars if you are on a gcc-6.0.0 
package (it may be fixed in gcc-6.1.1-2.fc24 which has just come out but I 
haven't tested it yet).

	Michael Young

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

Re: Build problems with xen 4.7

[Konrad Rzeszutek Wilk]

On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote:
> On Fri, 13 May 2016, Jan Beulich wrote:
> 
> > >>> On 13.05.16 at 15:49, <konrad.wilk@oracle.com> wrote:
> > > ...
> > > 
> > > Still an issue - with 4.7.0-rc1.
> > 
> > And I don't recall anyone having contributed a fix/workaround.
> > 
> > > If I do:
> > > 
> > > $export CFLAGS=" "'
> > > $make
> > > 
> > > I end up with:
> > > gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 
> > >[...]
> > > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> > > <command-line>:0:0: note: this is the location of the previous definition
> > > <command-line>:0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
> > > <command-line>:0:0: note: this is the location of the previous definition
> > > cc1: all warnings being treated as errors
> > > Makefile:62: recipe for target 'compat/callback.i' failed
> > 
> > My previous recommendation stands: Then just don't do this.
> 
> I hacked around it for my test builds (eg. see my test build at
> https://copr.fedorainfracloud.org/coprs/myoung/xentest/build/204111/
> ) by not setting CFLAGS in the environment, but by instead adding the 
> recommended Fedora RPM settings into config/StdGNU.mk via a different 
> environment variable.

ah:

--- 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
 else
 # Less than -O1 produces bad code and large stack frames
 CFLAGS += -O1 -fno-omit-frame-pointer


And in the spec file:
export CFLAGS_EXTRA="$RPM_OPT_FLAGS"
make %{?_smp_mflags} %{?efi_flags} prefix=/usr dist-xen


> 
> Another thing you might need to know if you are building xen on Fedora 24 
> is that you need to add -fno-tree-coalesce-vars if you are on a gcc-6.0.0 
> package (it may be fixed in gcc-6.1.1-2.fc24 which has just come out but I 
> haven't tested it yet).
> 
> 	Michael Young

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

Re: Build problems with xen 4.7

[George Dunlap]

On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote:
>> On Fri, 13 May 2016, Jan Beulich wrote:
>>
>> > >>> On 13.05.16 at 15:49, <konrad.wilk@oracle.com> wrote:
>> > > ...
>> > >
>> > > Still an issue - with 4.7.0-rc1.
>> >
>> > And I don't recall anyone having contributed a fix/workaround.
>> >
>> > > If I do:
>> > >
>> > > $export CFLAGS=" "'
>> > > $make
>> > >
>> > > I end up with:
>> > > gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99
>> > >[...]
>> > > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
>> > > <command-line>:0:0: note: this is the location of the previous definition
>> > > <command-line>:0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
>> > > <command-line>:0:0: note: this is the location of the previous definition
>> > > cc1: all warnings being treated as errors
>> > > Makefile:62: recipe for target 'compat/callback.i' failed
>> >
>> > My previous recommendation stands: Then just don't do this.
>>
>> I hacked around it for my test builds (eg. see my test build at
>> https://copr.fedorainfracloud.org/coprs/myoung/xentest/build/204111/
>> ) by not setting CFLAGS in the environment, but by instead adding the
>> recommended Fedora RPM settings into config/StdGNU.mk via a different
>> environment variable.
>
> ah:
>
> --- 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
>  else
>  # Less than -O1 produces bad code and large stack frames
>  CFLAGS += -O1 -fno-omit-frame-pointer
>
>
> And in the spec file:
> export CFLAGS_EXTRA="$RPM_OPT_FLAGS"
> make %{?_smp_mflags} %{?efi_flags} prefix=/usr dist-xen

Something like the above solution worked for me (CentOS 7 -- I'm
suspecting a similar pattern here).

Adding CFLAGS="${RPM_OPT_FLAGS}" to my ./configure line made some
noises as though it was going to work, but none of it actually ended
up passed to the compiler (whereas it did with the little patch Konrad
posted).

Are we going to provide a proper way for distros to add flags like
this without having to hack the build system?

 -George

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

Re: Build problems with xen 4.7

[Konrad Rzeszutek Wilk]

On Tue, May 31, 2016 at 07:27:24PM +0100, George Dunlap wrote:
> On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote:
> >> On Fri, 13 May 2016, Jan Beulich wrote:
> >>
> >> > >>> On 13.05.16 at 15:49, <konrad.wilk@oracle.com> wrote:
> >> > > ...
> >> > >
> >> > > Still an issue - with 4.7.0-rc1.
> >> >
> >> > And I don't recall anyone having contributed a fix/workaround.
> >> >
> >> > > If I do:
> >> > >
> >> > > $export CFLAGS=" "'
> >> > > $make
> >> > >
> >> > > I end up with:
> >> > > gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99
> >> > >[...]
> >> > > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> >> > > <command-line>:0:0: note: this is the location of the previous definition
> >> > > <command-line>:0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
> >> > > <command-line>:0:0: note: this is the location of the previous definition
> >> > > cc1: all warnings being treated as errors
> >> > > Makefile:62: recipe for target 'compat/callback.i' failed
> >> >
> >> > My previous recommendation stands: Then just don't do this.
> >>
> >> I hacked around it for my test builds (eg. see my test build at
> >> https://copr.fedorainfracloud.org/coprs/myoung/xentest/build/204111/
> >> ) by not setting CFLAGS in the environment, but by instead adding the
> >> recommended Fedora RPM settings into config/StdGNU.mk via a different
> >> environment variable.
> >
> > ah:
> >
> > --- 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
> >  else
> >  # Less than -O1 produces bad code and large stack frames
> >  CFLAGS += -O1 -fno-omit-frame-pointer
> >
> >
> > And in the spec file:
> > export CFLAGS_EXTRA="$RPM_OPT_FLAGS"
> > make %{?_smp_mflags} %{?efi_flags} prefix=/usr dist-xen
> 
> Something like the above solution worked for me (CentOS 7 -- I'm
> suspecting a similar pattern here).
> 
> Adding CFLAGS="${RPM_OPT_FLAGS}" to my ./configure line made some
> noises as though it was going to work, but none of it actually ended
> up passed to the compiler (whereas it did with the little patch Konrad
> posted).
> 
> Are we going to provide a proper way for distros to add flags like
> this without having to hack the build system?

I like the suggestion he had for config/StdGNU.mk ..
> 
>  -George

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

Re: Build problems with xen 4.7

[George Dunlap]

On Tue, May 31, 2016 at 9:57 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, May 31, 2016 at 07:27:24PM +0100, George Dunlap wrote:
>> On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk
>> <konrad.wilk@oracle.com> wrote:
>> > On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote:
>> >> On Fri, 13 May 2016, Jan Beulich wrote:
>> >>
>> >> > >>> On 13.05.16 at 15:49, <konrad.wilk@oracle.com> wrote:
>> >> > > ...
>> >> > >
>> >> > > Still an issue - with 4.7.0-rc1.
>> >> >
>> >> > And I don't recall anyone having contributed a fix/workaround.
>> >> >
>> >> > > If I do:
>> >> > >
>> >> > > $export CFLAGS=" "'
>> >> > > $make
>> >> > >
>> >> > > I end up with:
>> >> > > gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99
>> >> > >[...]
>> >> > > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
>> >> > > <command-line>:0:0: note: this is the location of the previous definition
>> >> > > <command-line>:0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
>> >> > > <command-line>:0:0: note: this is the location of the previous definition
>> >> > > cc1: all warnings being treated as errors
>> >> > > Makefile:62: recipe for target 'compat/callback.i' failed
>> >> >
>> >> > My previous recommendation stands: Then just don't do this.
>> >>
>> >> I hacked around it for my test builds (eg. see my test build at
>> >> https://copr.fedorainfracloud.org/coprs/myoung/xentest/build/204111/
>> >> ) by not setting CFLAGS in the environment, but by instead adding the
>> >> recommended Fedora RPM settings into config/StdGNU.mk via a different
>> >> environment variable.
>> >
>> > ah:
>> >
>> > --- 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
>> >  else
>> >  # Less than -O1 produces bad code and large stack frames
>> >  CFLAGS += -O1 -fno-omit-frame-pointer
>> >
>> >
>> > And in the spec file:
>> > export CFLAGS_EXTRA="$RPM_OPT_FLAGS"
>> > make %{?_smp_mflags} %{?efi_flags} prefix=/usr dist-xen
>>
>> Something like the above solution worked for me (CentOS 7 -- I'm
>> suspecting a similar pattern here).
>>
>> Adding CFLAGS="${RPM_OPT_FLAGS}" to my ./configure line made some
>> noises as though it was going to work, but none of it actually ended
>> up passed to the compiler (whereas it did with the little patch Konrad
>> posted).
>>
>> Are we going to provide a proper way for distros to add flags like
>> this without having to hack the build system?
>
> I like the suggestion he had for config/StdGNU.mk ..

Do you want to submit the patch upstream then, or shall I? :-)

 -George

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

Re: Build problems with xen 4.7

[Konrad Rzeszutek Wilk]

On Fri, Jun 03, 2016 at 12:20:16PM +0100, George Dunlap wrote:
> On Tue, May 31, 2016 at 9:57 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Tue, May 31, 2016 at 07:27:24PM +0100, George Dunlap wrote:
> >> On Fri, May 13, 2016 at 4:23 PM, Konrad Rzeszutek Wilk
> >> <konrad.wilk@oracle.com> wrote:
> >> > On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote:
> >> >> On Fri, 13 May 2016, Jan Beulich wrote:
> >> >>
> >> >> > >>> On 13.05.16 at 15:49, <konrad.wilk@oracle.com> wrote:
> >> >> > > ...
> >> >> > >
> >> >> > > Still an issue - with 4.7.0-rc1.
> >> >> >
> >> >> > And I don't recall anyone having contributed a fix/workaround.
> >> >> >
> >> >> > > If I do:
> >> >> > >
> >> >> > > $export CFLAGS=" "'
> >> >> > > $make
> >> >> > >
> >> >> > > I end up with:
> >> >> > > gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99
> >> >> > >[...]
> >> >> > > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> >> >> > > <command-line>:0:0: note: this is the location of the previous definition
> >> >> > > <command-line>:0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
> >> >> > > <command-line>:0:0: note: this is the location of the previous definition
> >> >> > > cc1: all warnings being treated as errors
> >> >> > > Makefile:62: recipe for target 'compat/callback.i' failed
> >> >> >
> >> >> > My previous recommendation stands: Then just don't do this.
> >> >>
> >> >> I hacked around it for my test builds (eg. see my test build at
> >> >> https://copr.fedorainfracloud.org/coprs/myoung/xentest/build/204111/
> >> >> ) by not setting CFLAGS in the environment, but by instead adding the
> >> >> recommended Fedora RPM settings into config/StdGNU.mk via a different
> >> >> environment variable.
> >> >
> >> > ah:
> >> >
> >> > --- 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
> >> >  else
> >> >  # Less than -O1 produces bad code and large stack frames
> >> >  CFLAGS += -O1 -fno-omit-frame-pointer
> >> >
> >> >
> >> > And in the spec file:
> >> > export CFLAGS_EXTRA="$RPM_OPT_FLAGS"
> >> > make %{?_smp_mflags} %{?efi_flags} prefix=/usr dist-xen
> >>
> >> Something like the above solution worked for me (CentOS 7 -- I'm
> >> suspecting a similar pattern here).
> >>
> >> Adding CFLAGS="${RPM_OPT_FLAGS}" to my ./configure line made some
> >> noises as though it was going to work, but none of it actually ended
> >> up passed to the compiler (whereas it did with the little patch Konrad
> >> posted).
> >>
> >> Are we going to provide a proper way for distros to add flags like
> >> this without having to hack the build system?
> >
> > I like the suggestion he had for config/StdGNU.mk ..
> 
> Do you want to submit the patch upstream then, or shall I? :-)

I would love it if you could do it!

Thanks!
> 
>  -George

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

Re: Build problems with xen 4.7

[George Dunlap]

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?

 -George

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

Re: Build problems with xen 4.7

[M A Young]

On Tue, 7 Jun 2016, George Dunlap 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?

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

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

Re: Build problems with xen 4.7

[George Dunlap]

On Tue, Jun 7, 2016 at 11:42 AM, M A Young <m.a.young@durham.ac.uk> wrote:
> On Tue, 7 Jun 2016, George Dunlap 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?
>
> 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@lists.xen.org
http://lists.xen.org/xen-devel

Re: Build problems with xen 4.7

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 1642 bytes --]

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@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?
> 
> 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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Build problems with xen 4.7

[George Dunlap]

On Tue, Jun 7, 2016 at 12:33 PM, Doug Goldstein <cardoe@cardoe.com> wrote:
> 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@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?
>>
>> 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.

But I think these are *in general* meant to be the TARGET_ARCH's
cflags.  Michael is building packages for 32-bit fedora, so the tools
and everything actually do want to be 32-bit.  It's just the
hypervisor which is special -- it has to be compiled 64-bit even when
building "32-bit" packages.  So the -m32 needs to be filtered out of
the TARGET_ARCH -- the question is whether it should be done in the
makefiles, or in the RPM spec file.  I'm inclined to say the latter.

 -George

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

Re: Build problems with xen 4.7

[Olaf Hering]

On Tue, Jun 07, M A Young wrote:

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

What exactly are you doing anyway? If xen/ is supposed to be a 64bit
binary and tools/ should be 32bit then configure --disable-xen should be
used. 'make' will do the 32bit build, and 'make xen' the 64bit build.

Olaf

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

Re: Build problems with xen 4.7

[George Dunlap]

On Tue, Jun 7, 2016 at 3:00 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Tue, Jun 07, M A Young wrote:
>
>> 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.
>
> What exactly are you doing anyway? If xen/ is supposed to be a 64bit
> binary and tools/ should be 32bit then configure --disable-xen should be
> used. 'make' will do the 32bit build, and 'make xen' the 64bit build.

I assume he's trying to do this:

CFLAGS_EXTRA="$RPM_OPT_FLAGS"
make tools
make xen

For i686 packages, RPM_OPT_FLAGS will include -m32 (or something like it).

 -George

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

Re: Build problems with xen 4.7

[Olaf Hering]

On Tue, Jun 07, George Dunlap wrote:

> CFLAGS_EXTRA="$RPM_OPT_FLAGS"
> make tools
> make xen

Dont we have all that in place already?

export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
./configure --disable-xen
make
make xen CC=<whatever>

Olaf

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

Re: Build problems with xen 4.7

[George Dunlap]

On Tue, Jun 7, 2016 at 3:10 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Tue, Jun 07, George Dunlap wrote:
>
>> CFLAGS_EXTRA="$RPM_OPT_FLAGS"
>> make tools
>> make xen
>
> Dont we have all that in place already?
>
> export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
> export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
> export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
> ./configure --disable-xen
> make
> make xen CC=<whatever>

Ah, I didn't know about that feature.  Much better!

It looks like we could probably use with having the makefile *not*
pass EXTRA_CFLAGS_XEN_TOOLS into the stubdom build; but this solves my
problem.

We packagers -- at very least the RPM-based ones -- should make it a
point to get together once in a while to compare notes...

 -George

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

Re: Build problems with xen 4.7

[Jan Beulich]

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

Jan


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

Re: Build problems with xen 4.7

[M A Young]

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

Re: Build problems with xen 4.7

[Peng Fan]

Hi,

On Fri, May 13, 2016 at 11:23:29AM -0400, Konrad Rzeszutek Wilk wrote:
>On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote:
>> On Fri, 13 May 2016, Jan Beulich wrote:
>> 
>> > >>> On 13.05.16 at 15:49, <konrad.wilk@oracle.com> wrote:
>> > > ...
>> > > 
>> > > Still an issue - with 4.7.0-rc1.
>> > 
>> > And I don't recall anyone having contributed a fix/workaround.
>> > 
>> > > If I do:
>> > > 
>> > > $export CFLAGS=" "'
>> > > $make
>> > > 
>> > > I end up with:
>> > > gcc -E -O1 -fno-omit-frame-pointer -m64 -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 
>> > >[...]
>> > > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
>> > > <command-line>:0:0: note: this is the location of the previous definition
>> > > <command-line>:0:0: error: "__OBJECT_LABEL__" redefined [-Werror]
>> > > <command-line>:0:0: note: this is the location of the previous definition
>> > > cc1: all warnings being treated as errors
>> > > Makefile:62: recipe for target 'compat/callback.i' failed

I met similar issue when cross compile xen for ARM64 on X86 PC using yocto poky 4.9.3
toolchain.

aarch64-poky-linux-gcc -O2 -pipe -g -feliminate-unused-debug-types -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /home/Freenix/work/sw-stash/imx8/8qm/xen/xen/xen/include/xen/config.h '-D__OBJECT_FILE__="/home/Freenix/work/sw-stash/imx8/8qm/xen/xen/xen/xen"' -Wa,--strip-local-absolute -fno-optimize-sibling-calls -fno-omit-frame-pointer -MMD -MF /home/Freenix/work/sw-stash/imx8/8qm/xen/xen/xen/.xen.d -mcpu=generic -mgeneral-regs-only -DCONFIG_EARLY_PRINTK -DEARLY_PRINTK_INC=\"debug-imx8qm.inc\" -DEARLY_PRINTK_BAUD= -DEARLY_UART_BASE_ADDRESS=0x5a060000 -DEARLY_UART_REG_SHIFT= -fno-optimize-sibling-calls -I/home/Freenix/work/sw-stash/imx8/8qm/xen/xen/xen/include -fno-stack-protector -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /home/Freenix/work/sw-stash/imx8/8qm/xen/xen/xen/include/xen/config.h '-D__OBJECT_FILE__="asm-offsets.s"' -Wa,--strip-local-absolute -fno-optimize-sibling-calls -fno-omit-frame-pointer -MMD -MF ./.asm-offsets.s.d -mcpu=generic -mgeneral-regs-only -DCONFIG_EARLY_PRINTK -DEARLY_PRINTK_INC=\"debug-imx8qm.inc\" -DEARLY_PRINTK_BAUD= -DEARLY_UART_BASE_ADDRESS=0x5a060000 -DEARLY_UART_REG_SHIFT= -I/home/Freenix/work/sw-stash/imx8/8qm/xen/xen/xen/include -fno-stack-protector -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -S -o asm-offsets.s arm64/asm-offsets.c
<command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
<command-line>:0:0: note: this is the location of the previous definition
cc1: all warnings being treated as errors


>> > 
>> > My previous recommendation stands: Then just don't do this.
>> 
>> I hacked around it for my test builds (eg. see my test build at
>> https://copr.fedorainfracloud.org/coprs/myoung/xentest/build/204111/
>> ) by not setting CFLAGS in the environment, but by instead adding the 
>> recommended Fedora RPM settings into config/StdGNU.mk via a different 
>> environment variable.
>
>ah:
>
>--- 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
> else
> # Less than -O1 produces bad code and large stack frames
> CFLAGS += -O1 -fno-omit-frame-pointer
>
>
>And in the spec file:
>export CFLAGS_EXTRA="$RPM_OPT_FLAGS"
>make %{?_smp_mflags} %{?efi_flags} prefix=/usr dist-xen
>

Does this patch work when cross compile for ARM64?

Thanks,
Peng.

>
>> 
>> Another thing you might need to know if you are building xen on Fedora 24 
>> is that you need to add -fno-tree-coalesce-vars if you are on a gcc-6.0.0 
>> package (it may be fixed in gcc-6.1.1-2.fc24 which has just come out but I 
>> haven't tested it yet).
>> 
>> 	Michael Young
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/xen-devel

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

Re: Build problems with xen 4.7

[M A Young]

On Mon, 8 Aug 2016, Peng Fan wrote:

> ...
> <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> <command-line>:0:0: note: this is the location of the previous definition
> cc1: all warnings being treated as errors
>
> ...
>
> Does this patch work when cross compile for ARM64?

I dropped that patch following suggestions on this thread, and just did it 
in the spec file, where the relevant bit is

export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS"
export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS"
export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS"
%if %build_crosshyp
XEN_TARGET_ARCH=x86_64 make %{?_smp_mflags} %{?efi_flags} prefix=/usr xen CC="/usr/bin/x86_64-linux-gnu-gcc `echo $RPM_OPT_FLAGS | sed -e 's/-m32//g' -e 's/-march=i686//g' -e 's/-mtune=atom//g'`"
%else
make %{?_smp_mflags} %{?efi_flags} prefix=/usr xen CC="gcc $RPM_OPT_FLAGS"
%endif
./configure --prefix=%{_prefix} --libdir=%{_libdir} --with-system-seabios=%{seabiosloc} --with-system-qemu=/usr/bin/qemu-system-i386 --with-linux-backend-modules="xen-evtchn xen-gntdev xen-gntalloc xen-blkback xen-netback xen-pciback xen-scsiback xen-acpi-processor"
make %{?_smp_mflags} %{?ocaml_flags} prefix=/usr tools
make                 prefix=/usr docs
export RPM_OPT_FLAGS_RED=`echo $RPM_OPT_FLAGS | sed -e 's/-m64//g' -e 's/--param=ssp-buffer-size=4//g' -e's/-fstack-protector-strong//'`
%ifarch %{ix86}
export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS_RED"
%endif
make mini-os-dir
make -C stubdom build
%ifarch x86_64
export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS_RED"
XEN_TARGET_ARCH=x86_32 make -C stubdom pv-grub
%endif

which is a bit messy but seems to work. In summary you need not to set 
CFLAGS or unset it, and can instead pass extra compile options using
EXTRA_CFLAGS_XEN_TOOLS, EXTRA_CFLAGS_QEMU_TRADITIONAL and 
EXTRA_CFLAGS_QEMU_XEN and with CC="gcc compile_options" added to the make 
command for the hypervisor.

	Michael Young

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

Re: Build problems with xen 4.7

[M A Young]

On Tue, 1 Dec 2015, Jan Beulich wrote:

> >>> On 01.12.15 at 00:37, <m.a.young@durham.ac.uk> wrote:
> > When I try to build the current xen 4.7 master I get the following error
> > 
> > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> > <command-line>:0:0: note: this is the location of the previous definition
> > cc1: all warnings being treated as errors
> > 
> > The problem seems to be that -D__OBJECT_FILE__= is set each time 
> > xen/Rules.mk is called, which happens more than once because of nested 
> > makes resulting in multiple diffent values for -D__OBJECT_FILE__=
> 
> Considering you're the first one to have such a problem, I think the
> precise compiler version you use matters here. Also the redundant
> definitions shouldn't be different, and identical re-definition should
> not yield a diagnostic. So I think there's a little more data you need
> to supply in order to determine whether we need to adjust something.

This is just with Fedora's gcc-5.1.1-4.fc23.x86_64 with the standard 
package build options, including -Werror . The values of 
-D__OBJECT_FILE__= really are different, with (from memory) the first 
being the absolute path to the /xen subdirectory of the unpacked xen-4.7 
source and the second a relative path to the file being complied from 
there.

	Michael Young