* Build problems with xen 4.7
@ 2015-11-30 23:37 M A Young
2015-12-01 13:19 ` Jan Beulich
0 siblings, 1 reply; 33+ messages in thread
From: M A Young @ 2015-11-30 23:37 UTC (permalink / raw)
To: xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2015-11-30 23:37 Build problems with xen 4.7 M A Young
@ 2015-12-01 13:19 ` Jan Beulich
2015-12-01 14:36 ` Konrad Rzeszutek Wilk
2015-12-01 14:49 ` M A Young
0 siblings, 2 replies; 33+ messages in thread
From: Jan Beulich @ 2015-12-01 13:19 UTC (permalink / raw)
To: M A Young; +Cc: xen-devel
>>> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2015-12-01 13:19 ` Jan Beulich
@ 2015-12-01 14:36 ` Konrad Rzeszutek Wilk
2015-12-01 14:50 ` Marcos E. Matsunaga
2015-12-01 15:56 ` Jan Beulich
2015-12-01 14:49 ` M A Young
1 sibling, 2 replies; 33+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-12-01 14:36 UTC (permalink / raw)
To: Jan Beulich, M A Young, Marcos Matsunaga; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2015-12-01 13:19 ` Jan Beulich
2015-12-01 14:36 ` Konrad Rzeszutek Wilk
@ 2015-12-01 14:49 ` M A Young
1 sibling, 0 replies; 33+ messages in thread
From: M A Young @ 2015-12-01 14:49 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2015-12-01 14:36 ` Konrad Rzeszutek Wilk
@ 2015-12-01 14:50 ` Marcos E. Matsunaga
2015-12-01 15:56 ` Jan Beulich
1 sibling, 0 replies; 33+ messages in thread
From: Marcos E. Matsunaga @ 2015-12-01 14:50 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Jan Beulich, M A Young; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2015-12-01 14:36 ` Konrad Rzeszutek Wilk
2015-12-01 14:50 ` Marcos E. Matsunaga
@ 2015-12-01 15:56 ` Jan Beulich
2015-12-01 15:59 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 33+ messages in thread
From: Jan Beulich @ 2015-12-01 15:56 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Marcos Matsunaga, xen-devel, M A Young
>>> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2015-12-01 15:56 ` Jan Beulich
@ 2015-12-01 15:59 ` Konrad Rzeszutek Wilk
2015-12-01 16:09 ` Jan Beulich
2016-05-13 13:49 ` Konrad Rzeszutek Wilk
0 siblings, 2 replies; 33+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-12-01 15:59 UTC (permalink / raw)
To: Jan Beulich; +Cc: Marcos Matsunaga, xen-devel, M A Young
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
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2015-12-01 15:59 ` Konrad Rzeszutek Wilk
@ 2015-12-01 16:09 ` Jan Beulich
2015-12-01 18:47 ` M A Young
2016-05-13 13:49 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 33+ messages in thread
From: Jan Beulich @ 2015-12-01 16:09 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Marcos Matsunaga, xen-devel, M A Young
>>> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2015-12-01 16:09 ` Jan Beulich
@ 2015-12-01 18:47 ` M A Young
2015-12-01 19:40 ` Olaf Hering
2015-12-02 10:05 ` Jan Beulich
0 siblings, 2 replies; 33+ messages in thread
From: M A Young @ 2015-12-01 18:47 UTC (permalink / raw)
To: Jan Beulich; +Cc: Marcos Matsunaga, xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2015-12-01 18:47 ` M A Young
@ 2015-12-01 19:40 ` Olaf Hering
2015-12-01 19:53 ` Andrew Cooper
2015-12-02 10:05 ` Jan Beulich
1 sibling, 1 reply; 33+ messages in thread
From: Olaf Hering @ 2015-12-01 19:40 UTC (permalink / raw)
To: M A Young; +Cc: Marcos Matsunaga, Jan Beulich, xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2015-12-01 19:40 ` Olaf Hering
@ 2015-12-01 19:53 ` Andrew Cooper
0 siblings, 0 replies; 33+ messages in thread
From: Andrew Cooper @ 2015-12-01 19:53 UTC (permalink / raw)
To: Olaf Hering, M A Young; +Cc: Marcos Matsunaga, Jan Beulich, xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2015-12-01 18:47 ` M A Young
2015-12-01 19:40 ` Olaf Hering
@ 2015-12-02 10:05 ` Jan Beulich
1 sibling, 0 replies; 33+ messages in thread
From: Jan Beulich @ 2015-12-02 10:05 UTC (permalink / raw)
To: M A Young; +Cc: Marcos Matsunaga, xen-devel
>>> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2015-12-01 15:59 ` Konrad Rzeszutek Wilk
2015-12-01 16:09 ` Jan Beulich
@ 2016-05-13 13:49 ` Konrad Rzeszutek Wilk
2016-05-13 14:01 ` Jan Beulich
1 sibling, 1 reply; 33+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-05-13 13:49 UTC (permalink / raw)
To: Jan Beulich; +Cc: Marcos Matsunaga, xen-devel, M A Young
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-05-13 13:49 ` Konrad Rzeszutek Wilk
@ 2016-05-13 14:01 ` Jan Beulich
2016-05-13 14:25 ` M A Young
0 siblings, 1 reply; 33+ messages in thread
From: Jan Beulich @ 2016-05-13 14:01 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Marcos Matsunaga, xen-devel, M A Young
>>> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-05-13 14:01 ` Jan Beulich
@ 2016-05-13 14:25 ` M A Young
2016-05-13 15:23 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 33+ messages in thread
From: M A Young @ 2016-05-13 14:25 UTC (permalink / raw)
To: Jan Beulich; +Cc: Marcos Matsunaga, xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-05-13 14:25 ` M A Young
@ 2016-05-13 15:23 ` Konrad Rzeszutek Wilk
2016-05-31 18:27 ` George Dunlap
` (2 more replies)
0 siblings, 3 replies; 33+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-05-13 15:23 UTC (permalink / raw)
To: M A Young; +Cc: Marcos Matsunaga, Jan Beulich, xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-05-13 15:23 ` Konrad Rzeszutek Wilk
@ 2016-05-31 18:27 ` George Dunlap
2016-05-31 20:57 ` Konrad Rzeszutek Wilk
2016-06-07 10:35 ` George Dunlap
2016-08-08 14:37 ` Peng Fan
2 siblings, 1 reply; 33+ messages in thread
From: George Dunlap @ 2016-05-31 18:27 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Marcos Matsunaga, xen-devel, Jan Beulich, M A Young
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-05-31 18:27 ` George Dunlap
@ 2016-05-31 20:57 ` Konrad Rzeszutek Wilk
2016-06-03 11:20 ` George Dunlap
0 siblings, 1 reply; 33+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-05-31 20:57 UTC (permalink / raw)
To: George Dunlap; +Cc: Marcos Matsunaga, xen-devel, Jan Beulich, M A Young
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-05-31 20:57 ` Konrad Rzeszutek Wilk
@ 2016-06-03 11:20 ` George Dunlap
2016-06-03 17:03 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 33+ messages in thread
From: George Dunlap @ 2016-06-03 11:20 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Marcos Matsunaga, M A Young, Jan Beulich, xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-06-03 11:20 ` George Dunlap
@ 2016-06-03 17:03 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 33+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-06-03 17:03 UTC (permalink / raw)
To: George Dunlap; +Cc: Marcos Matsunaga, M A Young, Jan Beulich, xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-05-13 15:23 ` Konrad Rzeszutek Wilk
2016-05-31 18:27 ` George Dunlap
@ 2016-06-07 10:35 ` George Dunlap
2016-06-07 10:42 ` M A Young
2016-06-07 10:43 ` Jan Beulich
2016-08-08 14:37 ` Peng Fan
2 siblings, 2 replies; 33+ messages in thread
From: George Dunlap @ 2016-06-07 10:35 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Marcos Matsunaga, xen-devel, Jan Beulich, M A Young
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-06-07 10:35 ` George Dunlap
@ 2016-06-07 10:42 ` M A Young
2016-06-07 10:50 ` George Dunlap
` (2 more replies)
2016-06-07 10:43 ` Jan Beulich
1 sibling, 3 replies; 33+ messages in thread
From: M A Young @ 2016-06-07 10:42 UTC (permalink / raw)
To: George Dunlap; +Cc: Marcos Matsunaga, xen-devel, Jan Beulich
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-06-07 10:35 ` George Dunlap
2016-06-07 10:42 ` M A Young
@ 2016-06-07 10:43 ` Jan Beulich
2016-06-07 10:52 ` M A Young
1 sibling, 1 reply; 33+ messages in thread
From: Jan Beulich @ 2016-06-07 10:43 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, George Dunlap
Cc: Marcos Matsunaga, xen-devel, M A Young
>>> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-06-07 10:42 ` M A Young
@ 2016-06-07 10:50 ` George Dunlap
2016-06-07 11:33 ` Doug Goldstein
2016-06-07 14:00 ` Olaf Hering
2 siblings, 0 replies; 33+ messages in thread
From: George Dunlap @ 2016-06-07 10:50 UTC (permalink / raw)
To: M A Young; +Cc: Marcos Matsunaga, Jan Beulich, xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-06-07 10:43 ` Jan Beulich
@ 2016-06-07 10:52 ` M A Young
0 siblings, 0 replies; 33+ messages in thread
From: M A Young @ 2016-06-07 10:52 UTC (permalink / raw)
To: Jan Beulich; +Cc: George Dunlap, xen-devel, Marcos Matsunaga
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-06-07 10:42 ` M A Young
2016-06-07 10:50 ` George Dunlap
@ 2016-06-07 11:33 ` Doug Goldstein
2016-06-07 13:48 ` George Dunlap
2016-06-07 14:00 ` Olaf Hering
2 siblings, 1 reply; 33+ messages in thread
From: Doug Goldstein @ 2016-06-07 11:33 UTC (permalink / raw)
To: M A Young, George Dunlap; +Cc: Marcos Matsunaga, Jan Beulich, xen-devel
[-- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-06-07 11:33 ` Doug Goldstein
@ 2016-06-07 13:48 ` George Dunlap
0 siblings, 0 replies; 33+ messages in thread
From: George Dunlap @ 2016-06-07 13:48 UTC (permalink / raw)
To: Doug Goldstein; +Cc: Marcos Matsunaga, xen-devel, Jan Beulich, M A Young
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-06-07 10:42 ` M A Young
2016-06-07 10:50 ` George Dunlap
2016-06-07 11:33 ` Doug Goldstein
@ 2016-06-07 14:00 ` Olaf Hering
2016-06-07 14:04 ` George Dunlap
2 siblings, 1 reply; 33+ messages in thread
From: Olaf Hering @ 2016-06-07 14:00 UTC (permalink / raw)
To: M A Young; +Cc: George Dunlap, Marcos Matsunaga, Jan Beulich, xen-devel
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-06-07 14:00 ` Olaf Hering
@ 2016-06-07 14:04 ` George Dunlap
2016-06-07 14:10 ` Olaf Hering
0 siblings, 1 reply; 33+ messages in thread
From: George Dunlap @ 2016-06-07 14:04 UTC (permalink / raw)
To: Olaf Hering; +Cc: Marcos Matsunaga, xen-devel, Jan Beulich, M A Young
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-06-07 14:04 ` George Dunlap
@ 2016-06-07 14:10 ` Olaf Hering
2016-06-08 10:20 ` George Dunlap
0 siblings, 1 reply; 33+ messages in thread
From: Olaf Hering @ 2016-06-07 14:10 UTC (permalink / raw)
To: George Dunlap; +Cc: Marcos Matsunaga, xen-devel, Jan Beulich, M A Young
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-06-07 14:10 ` Olaf Hering
@ 2016-06-08 10:20 ` George Dunlap
0 siblings, 0 replies; 33+ messages in thread
From: George Dunlap @ 2016-06-08 10:20 UTC (permalink / raw)
To: Olaf Hering; +Cc: Marcos Matsunaga, xen-devel, Jan Beulich, M A Young
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-05-13 15:23 ` Konrad Rzeszutek Wilk
2016-05-31 18:27 ` George Dunlap
2016-06-07 10:35 ` George Dunlap
@ 2016-08-08 14:37 ` Peng Fan
2016-08-08 19:22 ` M A Young
2 siblings, 1 reply; 33+ messages in thread
From: Peng Fan @ 2016-08-08 14:37 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, julien.grall
Cc: Marcos Matsunaga, xen-devel, Jan Beulich, M A Young
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Build problems with xen 4.7
2016-08-08 14:37 ` Peng Fan
@ 2016-08-08 19:22 ` M A Young
0 siblings, 0 replies; 33+ messages in thread
From: M A Young @ 2016-08-08 19:22 UTC (permalink / raw)
To: Peng Fan; +Cc: julien.grall, xen-devel, Marcos Matsunaga, Jan Beulich
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
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2016-08-08 19:22 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-30 23:37 Build problems with xen 4.7 M A Young
2015-12-01 13:19 ` Jan Beulich
2015-12-01 14:36 ` Konrad Rzeszutek Wilk
2015-12-01 14:50 ` Marcos E. Matsunaga
2015-12-01 15:56 ` Jan Beulich
2015-12-01 15:59 ` Konrad Rzeszutek Wilk
2015-12-01 16:09 ` Jan Beulich
2015-12-01 18:47 ` M A Young
2015-12-01 19:40 ` Olaf Hering
2015-12-01 19:53 ` Andrew Cooper
2015-12-02 10:05 ` Jan Beulich
2016-05-13 13:49 ` Konrad Rzeszutek Wilk
2016-05-13 14:01 ` Jan Beulich
2016-05-13 14:25 ` M A Young
2016-05-13 15:23 ` Konrad Rzeszutek Wilk
2016-05-31 18:27 ` George Dunlap
2016-05-31 20:57 ` Konrad Rzeszutek Wilk
2016-06-03 11:20 ` George Dunlap
2016-06-03 17:03 ` Konrad Rzeszutek Wilk
2016-06-07 10:35 ` George Dunlap
2016-06-07 10:42 ` M A Young
2016-06-07 10:50 ` George Dunlap
2016-06-07 11:33 ` Doug Goldstein
2016-06-07 13:48 ` George Dunlap
2016-06-07 14:00 ` Olaf Hering
2016-06-07 14:04 ` George Dunlap
2016-06-07 14:10 ` Olaf Hering
2016-06-08 10:20 ` George Dunlap
2016-06-07 10:43 ` Jan Beulich
2016-06-07 10:52 ` M A Young
2016-08-08 14:37 ` Peng Fan
2016-08-08 19:22 ` M A Young
2015-12-01 14:49 ` M A Young
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).