* 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 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: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: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-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: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-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
* 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
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).