* [Buildroot] [PATCH 1/2] xen: Disable -Werror when building @ 2016-09-13 20:45 Alistair Francis 2016-09-13 20:45 ` [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make Alistair Francis 2016-09-13 22:57 ` [Buildroot] [PATCH 1/2] xen: Disable -Werror when building Arnout Vandecappelle 0 siblings, 2 replies; 18+ messages in thread From: Alistair Francis @ 2016-09-13 20:45 UTC (permalink / raw) To: buildroot Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> --- ...1-Remove-hardcoded-strict-Werror-checking.patch | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch diff --git a/package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch b/package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch new file mode 100644 index 0000000..ca772dd --- /dev/null +++ b/package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch @@ -0,0 +1,26 @@ +From 234847440a5d3cf95540ea79f7a08d50cccfef73 Mon Sep 17 00:00:00 2001 +From: Alistair Francis <alistair.francis@xilinx.com> +Date: Tue, 13 Sep 2016 10:48:31 -0700 +Subject: [PATCH] Remove hardcoded strict -Werror checking + +Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> +--- + Config.mk | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/Config.mk b/Config.mk +index bd991c6..e7ac662 100644 +--- a/Config.mk ++++ b/Config.mk +@@ -36,7 +36,7 @@ CONFIG_$(XEN_OS) := y + SHELL ?= /bin/sh + + # Tools to run on system hosting the build +-HOSTCFLAGS = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer ++HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer + HOSTCFLAGS += -fno-strict-aliasing + + DISTDIR ?= $(XEN_ROOT)/dist +-- +2.7.4 + -- 2.7.4 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make 2016-09-13 20:45 [Buildroot] [PATCH 1/2] xen: Disable -Werror when building Alistair Francis @ 2016-09-13 20:45 ` Alistair Francis 2016-09-13 23:23 ` Arnout Vandecappelle 2016-10-22 21:18 ` Thomas Petazzoni 2016-09-13 22:57 ` [Buildroot] [PATCH 1/2] xen: Disable -Werror when building Arnout Vandecappelle 1 sibling, 2 replies; 18+ messages in thread From: Alistair Francis @ 2016-09-13 20:45 UTC (permalink / raw) To: buildroot The TARGET_CONFIGURE_OPTS variable resulted in a double definition error: <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror] Remove the options to avoid the error. Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> --- package/xen/xen.mk | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/package/xen/xen.mk b/package/xen/xen.mk index e2c797f..8400a77 100644 --- a/package/xen/xen.mk +++ b/package/xen/xen.mk @@ -22,8 +22,7 @@ XEN_CONF_OPTS = --disable-ocamltools XEN_CONF_ENV = PYTHON=$(HOST_DIR)/usr/bin/python2 XEN_MAKE_ENV = \ XEN_TARGET_ARCH=$(XEN_ARCH) \ - CROSS_COMPILE=$(TARGET_CROSS) \ - $(TARGET_CONFIGURE_OPTS) + CROSS_COMPILE=$(TARGET_CROSS) ifeq ($(BR2_PACKAGE_XEN_HYPERVISOR),y) XEN_MAKE_OPTS += dist-xen -- 2.7.4 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make 2016-09-13 20:45 ` [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make Alistair Francis @ 2016-09-13 23:23 ` Arnout Vandecappelle 2016-09-17 14:09 ` Thomas Petazzoni 2016-10-22 21:18 ` Thomas Petazzoni 1 sibling, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2016-09-13 23:23 UTC (permalink / raw) To: buildroot On 13-09-16 22:45, Alistair Francis wrote: > The TARGET_CONFIGURE_OPTS variable resulted in a double definition > error: > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror] > > Remove the options to avoid the error. This doesn't look right. TARGET_CONFIGURE_OPTS definitely doesn't contain -D__OBJECT_FILE__ (or you have some very weird stuff in BR2_TARGET_OPTIMIZATION). How did you get this error? Can you print the full command line (by setting BR2_DEBUG_WRAPPER=1 in the environment) to find out how it gets defined twice? Regards, Arnout > > Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> > --- > package/xen/xen.mk | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/package/xen/xen.mk b/package/xen/xen.mk > index e2c797f..8400a77 100644 > --- a/package/xen/xen.mk > +++ b/package/xen/xen.mk > @@ -22,8 +22,7 @@ XEN_CONF_OPTS = --disable-ocamltools > XEN_CONF_ENV = PYTHON=$(HOST_DIR)/usr/bin/python2 > XEN_MAKE_ENV = \ > XEN_TARGET_ARCH=$(XEN_ARCH) \ > - CROSS_COMPILE=$(TARGET_CROSS) \ > - $(TARGET_CONFIGURE_OPTS) > + CROSS_COMPILE=$(TARGET_CROSS) > > ifeq ($(BR2_PACKAGE_XEN_HYPERVISOR),y) > XEN_MAKE_OPTS += dist-xen > -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make 2016-09-13 23:23 ` Arnout Vandecappelle @ 2016-09-17 14:09 ` Thomas Petazzoni 2016-09-17 14:44 ` Thomas Petazzoni 2016-09-19 18:41 ` Alistair Francis 0 siblings, 2 replies; 18+ messages in thread From: Thomas Petazzoni @ 2016-09-17 14:09 UTC (permalink / raw) To: buildroot Hello, On Wed, 14 Sep 2016 01:23:32 +0200, Arnout Vandecappelle wrote: > On 13-09-16 22:45, Alistair Francis wrote: > > The TARGET_CONFIGURE_OPTS variable resulted in a double definition > > error: > > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror] > > > > Remove the options to avoid the error. > > This doesn't look right. TARGET_CONFIGURE_OPTS definitely doesn't > contain -D__OBJECT_FILE__ (or you have some very weird stuff in > BR2_TARGET_OPTIMIZATION). It doesn't look right, but it's actually what happens. When we pass our TARGET_CONFIGURE_OPTS, what happens is: /home/thomas/projets/buildroot/output/host/usr/bin/aarch64-linux-gnu-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -DNDEBUG -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include/xen/config.h '-D__OBJECT_FILE__="/home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/xen"' -Wa,--strip-local-absolute -MMD -MF /home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/.xen.d -mcpu=generic -mgeneral-regs-only -I/home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include -fno-stack-protector -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -DNDEBUG -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include/xen/config.h '-D__OBJECT_FILE__="asm-offsets.s"' -Wa,--strip-local-absolute -MMD -MF ./.asm-offsets.s.d -mcpu=generic -mgeneral-regs-only -I/home/thomas/projets/buildroot/output/build/xen-4.7.0/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 Makefile:103: recipe for target 'asm-offsets.s' failed make[5]: *** [asm-offsets.s] Error 1 So _OBJECT_FILE_ is really defined twice, once incorrectly, and the second time correctly. When we stop passing $(TARGET_CONFIGURE_OPTS), the same compilation step looks like this: /home/thomas/projets/buildroot/output/host/usr/bin/aarch64-linux-gnu-gcc -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -DNDEBUG -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include/xen/config.h '-D__OBJECT_FILE__="asm-offsets.s"' -Wa,--strip-local-absolute -MMD -MF ./.asm-offsets.s.d -mcpu=generic -mgeneral-regs-only -I/home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include -fno-stack-protector -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -S -o asm-offsets.s arm64/asm-offsets.c And the build succeeds. So apparently, the fact that we are passing our own CFLAGS confuses the Xen build system, which then adds its own CFLAGS twice for some reason. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make 2016-09-17 14:09 ` Thomas Petazzoni @ 2016-09-17 14:44 ` Thomas Petazzoni 2016-09-19 18:41 ` Alistair Francis 1 sibling, 0 replies; 18+ messages in thread From: Thomas Petazzoni @ 2016-09-17 14:44 UTC (permalink / raw) To: buildroot Hello, On Sat, 17 Sep 2016 16:09:47 +0200, Thomas Petazzoni wrote: > So apparently, the fact that we are passing our own CFLAGS confuses the > Xen build system, which then adds its own CFLAGS twice for some reason. Looking at the Xen Git history, this __OBJECT_FILE__ definition is new in 4.7.0 and did not exist in 4.6.0. So, this "duplication" of CFLAGS most likely already occurred with Xen 4.6.0, but was not noticed due to the fact that all other options can be passed several times. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make 2016-09-17 14:09 ` Thomas Petazzoni 2016-09-17 14:44 ` Thomas Petazzoni @ 2016-09-19 18:41 ` Alistair Francis 2016-10-03 18:06 ` Alistair Francis 1 sibling, 1 reply; 18+ messages in thread From: Alistair Francis @ 2016-09-19 18:41 UTC (permalink / raw) To: buildroot On Sat, Sep 17, 2016 at 7:09 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Wed, 14 Sep 2016 01:23:32 +0200, Arnout Vandecappelle wrote: >> On 13-09-16 22:45, Alistair Francis wrote: >> > The TARGET_CONFIGURE_OPTS variable resulted in a double definition >> > error: >> > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror] >> > >> > Remove the options to avoid the error. >> >> This doesn't look right. TARGET_CONFIGURE_OPTS definitely doesn't >> contain -D__OBJECT_FILE__ (or you have some very weird stuff in >> BR2_TARGET_OPTIMIZATION). > > It doesn't look right, but it's actually what happens. When we pass our > TARGET_CONFIGURE_OPTS, what happens is: > > /home/thomas/projets/buildroot/output/host/usr/bin/aarch64-linux-gnu-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable > -Wno-unused-local-typedefs -DNDEBUG -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include/xen/config.h '-D__OBJECT_FILE__="/home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/xen"' -Wa,--strip-local-absolute -MMD -MF /home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/.xen.d -mcpu=generic -mgeneral-regs-only -I/home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include -fno-stack-protector -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall > -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -DNDEBUG -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include/xen/config.h '-D__OBJECT_FILE__="asm-offsets.s"' -Wa,--strip-local-absolute -MMD -MF ./.asm-offsets.s.d -mcpu=generic -mgeneral-regs-only -I/home/thomas/projets/buildroot/output/build/xen-4.7.0/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 > Makefile:103: recipe for target 'asm-offsets.s' failed > make[5]: *** [asm-offsets.s] Error 1 > > So _OBJECT_FILE_ is really defined twice, once incorrectly, and the > second time correctly. > > When we stop passing $(TARGET_CONFIGURE_OPTS), the same compilation > step looks like this: > > /home/thomas/projets/buildroot/output/host/usr/bin/aarch64-linux-gnu-gcc -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -DNDEBUG -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include/xen/config.h '-D__OBJECT_FILE__="asm-offsets.s"' -Wa,--strip-local-absolute -MMD -MF ./.asm-offsets.s.d -mcpu=generic -mgeneral-regs-only -I/home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include -fno-stack-protector -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -S -o asm-offsets.s arm64/asm-offsets.c > > And the build succeeds. > > So apparently, the fact that we are passing our own CFLAGS confuses the > Xen build system, which then adds its own CFLAGS twice for some reason. That is exactly what I see as well. It was surprising to me as well, but the only way I could figure out how to fix this build issue was to remove the flags. Is this an acceptable solution, or do I need to look at the Xen build system and patch that to not add the duplicate options? Thanks, Alistair > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make 2016-09-19 18:41 ` Alistair Francis @ 2016-10-03 18:06 ` Alistair Francis 0 siblings, 0 replies; 18+ messages in thread From: Alistair Francis @ 2016-10-03 18:06 UTC (permalink / raw) To: buildroot On Mon, Sep 19, 2016 at 11:41 AM, Alistair Francis <alistair.francis@xilinx.com> wrote: > On Sat, Sep 17, 2016 at 7:09 AM, Thomas Petazzoni > <thomas.petazzoni@free-electrons.com> wrote: >> Hello, >> >> On Wed, 14 Sep 2016 01:23:32 +0200, Arnout Vandecappelle wrote: >>> On 13-09-16 22:45, Alistair Francis wrote: >>> > The TARGET_CONFIGURE_OPTS variable resulted in a double definition >>> > error: >>> > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror] >>> > >>> > Remove the options to avoid the error. >>> >>> This doesn't look right. TARGET_CONFIGURE_OPTS definitely doesn't >>> contain -D__OBJECT_FILE__ (or you have some very weird stuff in >>> BR2_TARGET_OPTIMIZATION). >> >> It doesn't look right, but it's actually what happens. When we pass our >> TARGET_CONFIGURE_OPTS, what happens is: >> >> /home/thomas/projets/buildroot/output/host/usr/bin/aarch64-linux-gnu-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable >> -Wno-unused-local-typedefs -DNDEBUG -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include/xen/config.h '-D__OBJECT_FILE__="/home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/xen"' -Wa,--strip-local-absolute -MMD -MF /home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/.xen.d -mcpu=generic -mgeneral-regs-only -I/home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include -fno-stack-protector -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall >> -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -DNDEBUG -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include/xen/config.h '-D__OBJECT_FILE__="asm-offsets.s"' -Wa,--strip-local-absolute -MMD -MF ./.asm-offsets.s.d -mcpu=generic -mgeneral-regs-only -I/home/thomas/projets/buildroot/output/build/xen-4.7.0/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 >> Makefile:103: recipe for target 'asm-offsets.s' failed >> make[5]: *** [asm-offsets.s] Error 1 >> >> So _OBJECT_FILE_ is really defined twice, once incorrectly, and the >> second time correctly. >> >> When we stop passing $(TARGET_CONFIGURE_OPTS), the same compilation >> step looks like this: >> >> /home/thomas/projets/buildroot/output/host/usr/bin/aarch64-linux-gnu-gcc -O2 -fomit-frame-pointer -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -DNDEBUG -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include/xen/config.h '-D__OBJECT_FILE__="asm-offsets.s"' -Wa,--strip-local-absolute -MMD -MF ./.asm-offsets.s.d -mcpu=generic -mgeneral-regs-only -I/home/thomas/projets/buildroot/output/build/xen-4.7.0/xen/include -fno-stack-protector -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -S -o asm-offsets.s arm64/asm-offsets.c >> >> And the build succeeds. >> >> So apparently, the fact that we are passing our own CFLAGS confuses the >> Xen build system, which then adds its own CFLAGS twice for some reason. > > That is exactly what I see as well. > > It was surprising to me as well, but the only way I could figure out > how to fix this build issue was to remove the flags. > > Is this an acceptable solution, or do I need to look at the Xen build > system and patch that to not add the duplicate options? Any opinions? I would like to fix the build issue soon. Thanks, Alistair > > Thanks, > > Alistair > >> >> Thomas >> -- >> Thomas Petazzoni, CTO, Free Electrons >> Embedded Linux and Kernel engineering >> http://free-electrons.com >> _______________________________________________ >> buildroot mailing list >> buildroot at busybox.net >> http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make 2016-09-13 20:45 ` [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make Alistair Francis 2016-09-13 23:23 ` Arnout Vandecappelle @ 2016-10-22 21:18 ` Thomas Petazzoni 2016-10-24 7:19 ` Alistair Francis 1 sibling, 1 reply; 18+ messages in thread From: Thomas Petazzoni @ 2016-10-22 21:18 UTC (permalink / raw) To: buildroot Hello, On Tue, 13 Sep 2016 13:45:04 -0700, Alistair Francis wrote: > The TARGET_CONFIGURE_OPTS variable resulted in a double definition > error: > <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror] > > Remove the options to avoid the error. > > Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Yann told me that you found the root cause of the problem during a short investigation session at ELCE. Could you share what the conclusion was? When do you expect to submit a patch? In the mean time, I've marked https://patchwork.ozlabs.org/patch/669641/ as Rejected, since this is clearly not the proper fix for the problem. Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make 2016-10-22 21:18 ` Thomas Petazzoni @ 2016-10-24 7:19 ` Alistair Francis 2016-10-28 20:26 ` Alistair Francis 0 siblings, 1 reply; 18+ messages in thread From: Alistair Francis @ 2016-10-24 7:19 UTC (permalink / raw) To: buildroot On Sat, Oct 22, 2016 at 11:18 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Tue, 13 Sep 2016 13:45:04 -0700, Alistair Francis wrote: >> The TARGET_CONFIGURE_OPTS variable resulted in a double definition >> error: >> <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror] >> >> Remove the options to avoid the error. >> >> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> > > Yann told me that you found the root cause of the problem during a > short investigation session at ELCE. Hey Thomas, Yeah, I talked to Yann and we worked out the problem and a hopeful fix. > > Could you share what the conclusion was? When do you expect to submit a > patch? I'm still traveling at the moment, but I should be able to send out the new patch this week with an explanation. > > In the mean time, I've marked > https://patchwork.ozlabs.org/patch/669641/ as Rejected, since this is > clearly not the proper fix for the problem. Sounds good to me. Thanks, Alistair > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make 2016-10-24 7:19 ` Alistair Francis @ 2016-10-28 20:26 ` Alistair Francis 2016-10-29 14:43 ` [Buildroot] [PATCH] package/xen: fix build failure on x86 after bump to 47 Yann E. MORIN 0 siblings, 1 reply; 18+ messages in thread From: Alistair Francis @ 2016-10-28 20:26 UTC (permalink / raw) To: buildroot On Mon, Oct 24, 2016 at 12:19 AM, Alistair Francis <alistair.francis@xilinx.com> wrote: > On Sat, Oct 22, 2016 at 11:18 PM, Thomas Petazzoni > <thomas.petazzoni@free-electrons.com> wrote: >> Hello, >> >> On Tue, 13 Sep 2016 13:45:04 -0700, Alistair Francis wrote: >>> The TARGET_CONFIGURE_OPTS variable resulted in a double definition >>> error: >>> <command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror] >>> >>> Remove the options to avoid the error. >>> >>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> >> >> Yann told me that you found the root cause of the problem during a >> short investigation session at ELCE. > > Hey Thomas, > > Yeah, I talked to Yann and we worked out the problem and a hopeful fix. The hopeful fix did work for this issue, but introduced another problem. It looks like the Xen 4.7 release just can't handle having the CFLAGS variable set either in the environment or in the options. This diff works for me, is this ok? Or should I try to find a Xen patch to fix it? diff --git a/package/xen/xen.mk b/package/xen/xen.mk index e2c797f..90240ec 100644 --- a/package/xen/xen.mk +++ b/package/xen/xen.mk @@ -22,8 +22,7 @@ XEN_CONF_OPTS = --disable-ocamltools XEN_CONF_ENV = PYTHON=$(HOST_DIR)/usr/bin/python2 XEN_MAKE_ENV = \ XEN_TARGET_ARCH=$(XEN_ARCH) \ - CROSS_COMPILE=$(TARGET_CROSS) \ - $(TARGET_CONFIGURE_OPTS) + CROSS_COMPILE=$(TARGET_CROSS) ifeq ($(BR2_PACKAGE_XEN_HYPERVISOR),y) XEN_MAKE_OPTS += dist-xen @@ -53,4 +52,8 @@ XEN_INSTALL_TARGET = NO XEN_CONF_OPTS += --disable-tools endif +# Remove the CFLAGS setter, otherwise the Xen build system won't append it's +# own options and will fail to compile. +XEN_MAKE_OPTS += $(shell echo '$(TARGET_CONFIGURE_OPTS)' | sed 's|CFLAGS=".*"||g') + $(eval $(autotools-package)) Thanks, Alistair > >> >> Could you share what the conclusion was? When do you expect to submit a >> patch? > > I'm still traveling at the moment, but I should be able to send out > the new patch this week with an explanation. > >> >> In the mean time, I've marked >> https://patchwork.ozlabs.org/patch/669641/ as Rejected, since this is >> clearly not the proper fix for the problem. > > Sounds good to me. > > Thanks, > > Alistair > >> >> Thanks! >> >> Thomas >> -- >> Thomas Petazzoni, CTO, Free Electrons >> Embedded Linux and Kernel engineering >> http://free-electrons.com >> _______________________________________________ >> buildroot mailing list >> buildroot at busybox.net >> http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/xen: fix build failure on x86 after bump to 47 2016-10-28 20:26 ` Alistair Francis @ 2016-10-29 14:43 ` Yann E. MORIN 2016-10-29 18:27 ` Yann E. MORIN 0 siblings, 1 reply; 18+ messages in thread From: Yann E. MORIN @ 2016-10-29 14:43 UTC (permalink / raw) To: buildroot Since the bump to 4.7, Xen fails to build because of a double definition of __OBJECT_FILE__. This is due to (who would have guessed) the weirdness of their buildsystem. Fix that with a dirty hack: undefine the macro before defining it. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Alistair Francis <alistair.francis@xilinx.com> --- Note: totally untested. --- ...mk-fix-build-with-CFLAGS-from-environment.patch | 36 ++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch diff --git a/package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch b/package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch new file mode 100644 index 0000000..0d4e581 --- /dev/null +++ b/package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch @@ -0,0 +1,36 @@ +From 2a310549aaeaba05f640ade43488bb893101ce4a Mon Sep 17 00:00:00 2001 +From: "Yann E. MORIN" <yann.morin.1998@free.fr> +Date: Sat, 29 Oct 2016 16:35:26 +0200 +Subject: [PATCH] xen/Rules.mk: fix build with CFLAGS from environment + +When CFLAGS are passed from the environment, the first-level make +invocation will append -D__OBJECT_FILE__ to it, then call a second +make invocation, that will have those new CFLAGS in its environment, +but will also append -D__OBJECT_FILE__ to those. + +Then, the compiler fails because __OBEJECT_FILE__ is defined twice. + +Just undefine it before defining it again, as a *workaround* to this +issue. + +Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> +--- + xen/Rules.mk | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/xen/Rules.mk b/xen/Rules.mk +index a9fda71..09ccbfa 100644 +--- a/xen/Rules.mk ++++ b/xen/Rules.mk +@@ -49,7 +49,7 @@ ALL_OBJS-$(CONFIG_CRYPTO) += $(BASEDIR)/crypto/built_in.o + CFLAGS += -nostdinc -fno-builtin -fno-common + CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith + CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h +-CFLAGS += '-D__OBJECT_FILE__="$@"' ++CFLAGS += -U__OBJECT_FILE__ '-D__OBJECT_FILE__="$@"' + + ifneq ($(clang),y) + # Clang doesn't understand this command line argument, and doesn't appear to +-- +2.7.4 + -- 2.7.4 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/xen: fix build failure on x86 after bump to 47 2016-10-29 14:43 ` [Buildroot] [PATCH] package/xen: fix build failure on x86 after bump to 47 Yann E. MORIN @ 2016-10-29 18:27 ` Yann E. MORIN 2016-10-31 22:06 ` Alistair Francis 0 siblings, 1 reply; 18+ messages in thread From: Yann E. MORIN @ 2016-10-29 18:27 UTC (permalink / raw) To: buildroot Alistair, All, On 2016-10-29 16:43 +0200, Yann E. MORIN spake thusly: > Since the bump to 4.7, Xen fails to build because of a double definition > of __OBJECT_FILE__. This is due to (who would have guessed) the weirdness > of their buildsystem. > > Fix that with a dirty hack: undefine the macro before defining it. > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > Cc: Alistair Francis <alistair.francis@xilinx.com> > > --- > Note: totally untested. Now build-tested, the double-definition issue is fixed, and the build succeeds with this defconfig: BR2_aarch64=y BR2_TOOLCHAIN_EXTERNAL=y BR2_PACKAGE_XEN=y BR2_PACKAGE_XEN_HYPERVISOR=y BR2_PACKAGE_XEN_TOOLS=y Not booted, I don't know Xen enough to test... Regards, Yann E. MORIN. > --- > ...mk-fix-build-with-CFLAGS-from-environment.patch | 36 ++++++++++++++++++++++ > 1 file changed, 36 insertions(+) > create mode 100644 package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch > > diff --git a/package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch b/package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch > new file mode 100644 > index 0000000..0d4e581 > --- /dev/null > +++ b/package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch > @@ -0,0 +1,36 @@ > +From 2a310549aaeaba05f640ade43488bb893101ce4a Mon Sep 17 00:00:00 2001 > +From: "Yann E. MORIN" <yann.morin.1998@free.fr> > +Date: Sat, 29 Oct 2016 16:35:26 +0200 > +Subject: [PATCH] xen/Rules.mk: fix build with CFLAGS from environment > + > +When CFLAGS are passed from the environment, the first-level make > +invocation will append -D__OBJECT_FILE__ to it, then call a second > +make invocation, that will have those new CFLAGS in its environment, > +but will also append -D__OBJECT_FILE__ to those. > + > +Then, the compiler fails because __OBEJECT_FILE__ is defined twice. > + > +Just undefine it before defining it again, as a *workaround* to this > +issue. > + > +Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > +--- > + xen/Rules.mk | 2 +- > + 1 file changed, 1 insertion(+), 1 deletion(-) > + > +diff --git a/xen/Rules.mk b/xen/Rules.mk > +index a9fda71..09ccbfa 100644 > +--- a/xen/Rules.mk > ++++ b/xen/Rules.mk > +@@ -49,7 +49,7 @@ ALL_OBJS-$(CONFIG_CRYPTO) += $(BASEDIR)/crypto/built_in.o > + CFLAGS += -nostdinc -fno-builtin -fno-common > + CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith > + CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h > +-CFLAGS += '-D__OBJECT_FILE__="$@"' > ++CFLAGS += -U__OBJECT_FILE__ '-D__OBJECT_FILE__="$@"' > + > + ifneq ($(clang),y) > + # Clang doesn't understand this command line argument, and doesn't appear to > +-- > +2.7.4 > + > -- > 2.7.4 > -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/xen: fix build failure on x86 after bump to 47 2016-10-29 18:27 ` Yann E. MORIN @ 2016-10-31 22:06 ` Alistair Francis 2016-11-01 0:42 ` Alistair Francis 0 siblings, 1 reply; 18+ messages in thread From: Alistair Francis @ 2016-10-31 22:06 UTC (permalink / raw) To: buildroot On Sat, Oct 29, 2016 at 11:27 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: > Alistair, All, > > On 2016-10-29 16:43 +0200, Yann E. MORIN spake thusly: >> Since the bump to 4.7, Xen fails to build because of a double definition >> of __OBJECT_FILE__. This is due to (who would have guessed) the weirdness >> of their buildsystem. >> >> Fix that with a dirty hack: undefine the macro before defining it. >> >> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> >> Cc: Alistair Francis <alistair.francis@xilinx.com> >> >> --- >> Note: totally untested. > > Now build-tested, the double-definition issue is fixed, and the build > succeeds with this defconfig: > > BR2_aarch64=y > BR2_TOOLCHAIN_EXTERNAL=y > BR2_PACKAGE_XEN=y > BR2_PACKAGE_XEN_HYPERVISOR=y > BR2_PACKAGE_XEN_TOOLS=y > > Not booted, I don't know Xen enough to test... The patch looks good to me! I just did a build test as well and it works, running a boot test now. Thanks, Alistair > > Regards, > Yann E. MORIN. > >> --- >> ...mk-fix-build-with-CFLAGS-from-environment.patch | 36 ++++++++++++++++++++++ >> 1 file changed, 36 insertions(+) >> create mode 100644 package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch >> >> diff --git a/package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch b/package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch >> new file mode 100644 >> index 0000000..0d4e581 >> --- /dev/null >> +++ b/package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch >> @@ -0,0 +1,36 @@ >> +From 2a310549aaeaba05f640ade43488bb893101ce4a Mon Sep 17 00:00:00 2001 >> +From: "Yann E. MORIN" <yann.morin.1998@free.fr> >> +Date: Sat, 29 Oct 2016 16:35:26 +0200 >> +Subject: [PATCH] xen/Rules.mk: fix build with CFLAGS from environment >> + >> +When CFLAGS are passed from the environment, the first-level make >> +invocation will append -D__OBJECT_FILE__ to it, then call a second >> +make invocation, that will have those new CFLAGS in its environment, >> +but will also append -D__OBJECT_FILE__ to those. >> + >> +Then, the compiler fails because __OBEJECT_FILE__ is defined twice. >> + >> +Just undefine it before defining it again, as a *workaround* to this >> +issue. >> + >> +Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> >> +--- >> + xen/Rules.mk | 2 +- >> + 1 file changed, 1 insertion(+), 1 deletion(-) >> + >> +diff --git a/xen/Rules.mk b/xen/Rules.mk >> +index a9fda71..09ccbfa 100644 >> +--- a/xen/Rules.mk >> ++++ b/xen/Rules.mk >> +@@ -49,7 +49,7 @@ ALL_OBJS-$(CONFIG_CRYPTO) += $(BASEDIR)/crypto/built_in.o >> + CFLAGS += -nostdinc -fno-builtin -fno-common >> + CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith >> + CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h >> +-CFLAGS += '-D__OBJECT_FILE__="$@"' >> ++CFLAGS += -U__OBJECT_FILE__ '-D__OBJECT_FILE__="$@"' >> + >> + ifneq ($(clang),y) >> + # Clang doesn't understand this command line argument, and doesn't appear to >> +-- >> +2.7.4 >> + >> -- >> 2.7.4 >> > > -- > .-----------------.--------------------.------------------.--------------------. > | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | > | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | > | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | > '------------------------------^-------^------------------^--------------------' > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/xen: fix build failure on x86 after bump to 47 2016-10-31 22:06 ` Alistair Francis @ 2016-11-01 0:42 ` Alistair Francis 2016-11-01 8:37 ` Yann E. MORIN 0 siblings, 1 reply; 18+ messages in thread From: Alistair Francis @ 2016-11-01 0:42 UTC (permalink / raw) To: buildroot On Mon, Oct 31, 2016 at 3:06 PM, Alistair Francis <alistair.francis@xilinx.com> wrote: > On Sat, Oct 29, 2016 at 11:27 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: >> Alistair, All, >> >> On 2016-10-29 16:43 +0200, Yann E. MORIN spake thusly: >>> Since the bump to 4.7, Xen fails to build because of a double definition >>> of __OBJECT_FILE__. This is due to (who would have guessed) the weirdness >>> of their buildsystem. >>> >>> Fix that with a dirty hack: undefine the macro before defining it. >>> >>> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> >>> Cc: Alistair Francis <alistair.francis@xilinx.com> >>> >>> --- >>> Note: totally untested. >> >> Now build-tested, the double-definition issue is fixed, and the build >> succeeds with this defconfig: >> >> BR2_aarch64=y >> BR2_TOOLCHAIN_EXTERNAL=y >> BR2_PACKAGE_XEN=y >> BR2_PACKAGE_XEN_HYPERVISOR=y >> BR2_PACKAGE_XEN_TOOLS=y >> >> Not booted, I don't know Xen enough to test... > > The patch looks good to me! > > I just did a build test as well and it works, running a boot test now. Tested on ARMv7 (little endian) boot. Tested-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> Thanks, Alistair > > Thanks, > > Alistair > >> >> Regards, >> Yann E. MORIN. >> >>> --- >>> ...mk-fix-build-with-CFLAGS-from-environment.patch | 36 ++++++++++++++++++++++ >>> 1 file changed, 36 insertions(+) >>> create mode 100644 package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch >>> >>> diff --git a/package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch b/package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch >>> new file mode 100644 >>> index 0000000..0d4e581 >>> --- /dev/null >>> +++ b/package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch >>> @@ -0,0 +1,36 @@ >>> +From 2a310549aaeaba05f640ade43488bb893101ce4a Mon Sep 17 00:00:00 2001 >>> +From: "Yann E. MORIN" <yann.morin.1998@free.fr> >>> +Date: Sat, 29 Oct 2016 16:35:26 +0200 >>> +Subject: [PATCH] xen/Rules.mk: fix build with CFLAGS from environment >>> + >>> +When CFLAGS are passed from the environment, the first-level make >>> +invocation will append -D__OBJECT_FILE__ to it, then call a second >>> +make invocation, that will have those new CFLAGS in its environment, >>> +but will also append -D__OBJECT_FILE__ to those. >>> + >>> +Then, the compiler fails because __OBEJECT_FILE__ is defined twice. >>> + >>> +Just undefine it before defining it again, as a *workaround* to this >>> +issue. >>> + >>> +Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> >>> +--- >>> + xen/Rules.mk | 2 +- >>> + 1 file changed, 1 insertion(+), 1 deletion(-) >>> + >>> +diff --git a/xen/Rules.mk b/xen/Rules.mk >>> +index a9fda71..09ccbfa 100644 >>> +--- a/xen/Rules.mk >>> ++++ b/xen/Rules.mk >>> +@@ -49,7 +49,7 @@ ALL_OBJS-$(CONFIG_CRYPTO) += $(BASEDIR)/crypto/built_in.o >>> + CFLAGS += -nostdinc -fno-builtin -fno-common >>> + CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith >>> + CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h >>> +-CFLAGS += '-D__OBJECT_FILE__="$@"' >>> ++CFLAGS += -U__OBJECT_FILE__ '-D__OBJECT_FILE__="$@"' >>> + >>> + ifneq ($(clang),y) >>> + # Clang doesn't understand this command line argument, and doesn't appear to >>> +-- >>> +2.7.4 >>> + >>> -- >>> 2.7.4 >>> >> >> -- >> .-----------------.--------------------.------------------.--------------------. >> | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | >> | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | >> | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | >> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | >> '------------------------------^-------^------------------^--------------------' >> _______________________________________________ >> buildroot mailing list >> buildroot at busybox.net >> http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH] package/xen: fix build failure on x86 after bump to 47 2016-11-01 0:42 ` Alistair Francis @ 2016-11-01 8:37 ` Yann E. MORIN 0 siblings, 0 replies; 18+ messages in thread From: Yann E. MORIN @ 2016-11-01 8:37 UTC (permalink / raw) To: buildroot Alistair, All, On 2016-10-31 17:42 -0700, Alistair Francis spake thusly: > On Mon, Oct 31, 2016 at 3:06 PM, Alistair Francis > <alistair.francis@xilinx.com> wrote: > > On Sat, Oct 29, 2016 at 11:27 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: > >> Alistair, All, > >> > >> On 2016-10-29 16:43 +0200, Yann E. MORIN spake thusly: > >>> Since the bump to 4.7, Xen fails to build because of a double definition > >>> of __OBJECT_FILE__. This is due to (who would have guessed) the weirdness > >>> of their buildsystem. > >>> > >>> Fix that with a dirty hack: undefine the macro before defining it. > >>> > >>> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > >>> Cc: Alistair Francis <alistair.francis@xilinx.com> > >>> > >>> --- > >>> Note: totally untested. > >> > >> Now build-tested, the double-definition issue is fixed, and the build > >> succeeds with this defconfig: > >> > >> BR2_aarch64=y > >> BR2_TOOLCHAIN_EXTERNAL=y > >> BR2_PACKAGE_XEN=y > >> BR2_PACKAGE_XEN_HYPERVISOR=y > >> BR2_PACKAGE_XEN_TOOLS=y > >> > >> Not booted, I don't know Xen enough to test... > > > > The patch looks good to me! > > > > I just did a build test as well and it works, running a boot test now. > > Tested on ARMv7 (little endian) boot. > > Tested-by: Alistair Francis <alistair.francis@xilinx.com> > Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> OK, thanks for the testing! I'll resend the patch officially now (it was not in patchwork). Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/2] xen: Disable -Werror when building 2016-09-13 20:45 [Buildroot] [PATCH 1/2] xen: Disable -Werror when building Alistair Francis 2016-09-13 20:45 ` [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make Alistair Francis @ 2016-09-13 22:57 ` Arnout Vandecappelle 2016-09-13 23:19 ` Arnout Vandecappelle 1 sibling, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2016-09-13 22:57 UTC (permalink / raw) To: buildroot On 13-09-16 22:45, Alistair Francis wrote: > Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> > --- > ...1-Remove-hardcoded-strict-Werror-checking.patch | 26 ++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > create mode 100644 package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch > > diff --git a/package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch b/package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch > new file mode 100644 > index 0000000..ca772dd > --- /dev/null > +++ b/package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch > @@ -0,0 +1,26 @@ > +From 234847440a5d3cf95540ea79f7a08d50cccfef73 Mon Sep 17 00:00:00 2001 > +From: Alistair Francis <alistair.francis@xilinx.com> > +Date: Tue, 13 Sep 2016 10:48:31 -0700 > +Subject: [PATCH] Remove hardcoded strict -Werror checking > + > +Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> > +--- > + Config.mk | 2 +- > + 1 file changed, 1 insertion(+), 1 deletion(-) > + > +diff --git a/Config.mk b/Config.mk > +index bd991c6..e7ac662 100644 > +--- a/Config.mk > ++++ b/Config.mk > +@@ -36,7 +36,7 @@ CONFIG_$(XEN_OS) := y > + SHELL ?= /bin/sh > + > + # Tools to run on system hosting the build > +-HOSTCFLAGS = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer > ++HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer I had a quick look, and there are actually roughly 60 instances of this -Werror spread out over various Makefiles... (It's an autotools package but it looks like it's not using automake.) Although we probably don't use some of them (components that don't get build, Makefiles meant for different targets, etc.), I doubt that removing this one instance is going to be sufficient. But a patch that changes those 60 instances doesn't sound very attractive either... Although, I must admit, the two errors encountered by the autobuilders come from kconfig which is clearly not -Werror-clean. Perhaps their own code really _is_ -Werror-clean. So we could start with this patch at least. Better still, work with upstream to find a solution. Regards, Arnout > + HOSTCFLAGS += -fno-strict-aliasing > + > + DISTDIR ?= $(XEN_ROOT)/dist > +-- > +2.7.4 > + > -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/2] xen: Disable -Werror when building 2016-09-13 22:57 ` [Buildroot] [PATCH 1/2] xen: Disable -Werror when building Arnout Vandecappelle @ 2016-09-13 23:19 ` Arnout Vandecappelle 2016-09-19 16:18 ` Alistair Francis 0 siblings, 1 reply; 18+ messages in thread From: Arnout Vandecappelle @ 2016-09-13 23:19 UTC (permalink / raw) To: buildroot On 14-09-16 00:57, Arnout Vandecappelle wrote: > > > On 13-09-16 22:45, Alistair Francis wrote: >> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> I forgot to mention before: the commit message should refer to the autobuilder failures. >> --- >> ...1-Remove-hardcoded-strict-Werror-checking.patch | 26 ++++++++++++++++++++++ >> 1 file changed, 26 insertions(+) >> create mode 100644 package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch >> >> diff --git a/package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch b/package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch >> new file mode 100644 >> index 0000000..ca772dd >> --- /dev/null >> +++ b/package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch >> @@ -0,0 +1,26 @@ >> +From 234847440a5d3cf95540ea79f7a08d50cccfef73 Mon Sep 17 00:00:00 2001 >> +From: Alistair Francis <alistair.francis@xilinx.com> >> +Date: Tue, 13 Sep 2016 10:48:31 -0700 >> +Subject: [PATCH] Remove hardcoded strict -Werror checking >> + >> +Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> >> +--- >> + Config.mk | 2 +- >> + 1 file changed, 1 insertion(+), 1 deletion(-) >> + >> +diff --git a/Config.mk b/Config.mk >> +index bd991c6..e7ac662 100644 >> +--- a/Config.mk >> ++++ b/Config.mk >> +@@ -36,7 +36,7 @@ CONFIG_$(XEN_OS) := y >> + SHELL ?= /bin/sh >> + >> + # Tools to run on system hosting the build >> +-HOSTCFLAGS = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer >> ++HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer > > I had a quick look, and there are actually roughly 60 instances of this -Werror > spread out over various Makefiles... (It's an autotools package but it looks > like it's not using automake.) Although we probably don't use some of them > (components that don't get build, Makefiles meant for different targets, etc.), > I doubt that removing this one instance is going to be sufficient. But a patch > that changes those 60 instances doesn't sound very attractive either... > > Although, I must admit, the two errors encountered by the autobuilders come > from kconfig which is clearly not -Werror-clean. Perhaps their own code really > _is_ -Werror-clean. So we could start with this patch at least. Now I replied to the other thread, I realized that the problem really is the combination of -Werror with -Wall. And a quick checks shows only three relevant occurrences of -Wall (but I may have missed something): two in Config.mk and one in tools/Rules.mk. So, I propose to accept this patch: Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> and look into removing the -Wall if needed for other build failures. > > Better still, work with upstream to find a solution. That's still true of course :-) Regards, Arnout > > Regards, > Arnout > > >> + HOSTCFLAGS += -fno-strict-aliasing >> + >> + DISTDIR ?= $(XEN_ROOT)/dist >> +-- >> +2.7.4 >> + >> > -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/2] xen: Disable -Werror when building 2016-09-13 23:19 ` Arnout Vandecappelle @ 2016-09-19 16:18 ` Alistair Francis 0 siblings, 0 replies; 18+ messages in thread From: Alistair Francis @ 2016-09-19 16:18 UTC (permalink / raw) To: buildroot On Tue, Sep 13, 2016 at 4:19 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > > > On 14-09-16 00:57, Arnout Vandecappelle wrote: >> >> >> On 13-09-16 22:45, Alistair Francis wrote: >>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> > > I forgot to mention before: the commit message should refer to the autobuilder > failures. Sorry, I didn't think of that. > >>> --- >>> ...1-Remove-hardcoded-strict-Werror-checking.patch | 26 ++++++++++++++++++++++ >>> 1 file changed, 26 insertions(+) >>> create mode 100644 package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch >>> >>> diff --git a/package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch b/package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch >>> new file mode 100644 >>> index 0000000..ca772dd >>> --- /dev/null >>> +++ b/package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch >>> @@ -0,0 +1,26 @@ >>> +From 234847440a5d3cf95540ea79f7a08d50cccfef73 Mon Sep 17 00:00:00 2001 >>> +From: Alistair Francis <alistair.francis@xilinx.com> >>> +Date: Tue, 13 Sep 2016 10:48:31 -0700 >>> +Subject: [PATCH] Remove hardcoded strict -Werror checking >>> + >>> +Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> >>> +--- >>> + Config.mk | 2 +- >>> + 1 file changed, 1 insertion(+), 1 deletion(-) >>> + >>> +diff --git a/Config.mk b/Config.mk >>> +index bd991c6..e7ac662 100644 >>> +--- a/Config.mk >>> ++++ b/Config.mk >>> +@@ -36,7 +36,7 @@ CONFIG_$(XEN_OS) := y >>> + SHELL ?= /bin/sh >>> + >>> + # Tools to run on system hosting the build >>> +-HOSTCFLAGS = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer >>> ++HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer >> >> I had a quick look, and there are actually roughly 60 instances of this -Werror >> spread out over various Makefiles... (It's an autotools package but it looks >> like it's not using automake.) Although we probably don't use some of them >> (components that don't get build, Makefiles meant for different targets, etc.), >> I doubt that removing this one instance is going to be sufficient. But a patch >> that changes those 60 instances doesn't sound very attractive either... Yeah, I saw that but I didn't want to delete every single one. So I just changed the one that fixed the build problem. This could end up with a game of cat and mouse though. As each new component breaks I will need to remove the -Werror from that Makefile. I'll try to work with mainline Xen and see if for the future there is a better fix. >> >> Although, I must admit, the two errors encountered by the autobuilders come >> from kconfig which is clearly not -Werror-clean. Perhaps their own code really >> _is_ -Werror-clean. So we could start with this patch at least. > > Now I replied to the other thread, I realized that the problem really is the > combination of -Werror with -Wall. And a quick checks shows only three relevant > occurrences of -Wall (but I may have missed something): two in Config.mk and one > in tools/Rules.mk. > > So, I propose to accept this patch: > > Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> > > and look into removing the -Wall if needed for other build failures. > >> >> Better still, work with upstream to find a solution. > > That's still true of course :-) Great! Thanks Alistair > > > Regards, > Arnout > >> >> Regards, >> Arnout >> >> >>> + HOSTCFLAGS += -fno-strict-aliasing >>> + >>> + DISTDIR ?= $(XEN_ROOT)/dist >>> +-- >>> +2.7.4 >>> + >>> >> > > -- > Arnout Vandecappelle arnout at mind be > Senior Embedded Software Architect +32-16-286500 > Essensium/Mind http://www.mind.be > G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven > LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle > GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2016-11-01 8:37 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-09-13 20:45 [Buildroot] [PATCH 1/2] xen: Disable -Werror when building Alistair Francis 2016-09-13 20:45 ` [Buildroot] [PATCH 2/2] xen: Remove TARGET_CONFIGURE_OPTS from make Alistair Francis 2016-09-13 23:23 ` Arnout Vandecappelle 2016-09-17 14:09 ` Thomas Petazzoni 2016-09-17 14:44 ` Thomas Petazzoni 2016-09-19 18:41 ` Alistair Francis 2016-10-03 18:06 ` Alistair Francis 2016-10-22 21:18 ` Thomas Petazzoni 2016-10-24 7:19 ` Alistair Francis 2016-10-28 20:26 ` Alistair Francis 2016-10-29 14:43 ` [Buildroot] [PATCH] package/xen: fix build failure on x86 after bump to 47 Yann E. MORIN 2016-10-29 18:27 ` Yann E. MORIN 2016-10-31 22:06 ` Alistair Francis 2016-11-01 0:42 ` Alistair Francis 2016-11-01 8:37 ` Yann E. MORIN 2016-09-13 22:57 ` [Buildroot] [PATCH 1/2] xen: Disable -Werror when building Arnout Vandecappelle 2016-09-13 23:19 ` Arnout Vandecappelle 2016-09-19 16:18 ` Alistair Francis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox