xen: Disable -Werror when building

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 <[email protected]>

---
 package/xen/xen.mk | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

package/xen/xen.mk +1 -2

index e2c797f..8400a77 100644
@@ -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

Quoted 5 lines · Alistair Francis

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

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.

Hello,

Quoted 10 lines · Arnout Vandecappelle

Quoted 5 lines · Alistair Francis

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

(quoted diff) +0 -2

-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
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 32 lines · Thomas Petazzoni

Hello,

Quoted 10 lines · Arnout Vandecappelle

Quoted 5 lines · Alistair Francis

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

(quoted diff) +0 -2

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

Quoted 6 lines

/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

Quoted 10 lines

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

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 <[email protected]>

Hello,

Quoted 4 lines · Alistair Francis

The TARGET_CONFIGURE_OPTS variable resulted in a double definition error:
<command-line>:0:0: error: "__OBJECT_FILE__" redefined [-Werror]

Quoted 3 lines

Remove the options to avoid the error.

Signed-off-by Alistair Francis <[email protected]>

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
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 9 lines · Thomas Petazzoni

Hello,

Quoted 6 lines · Alistair Francis

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.

Quoted 4 lines

Quoted 1 line

Signed-off-by Alistair Francis <[email protected]>

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.

Quoted 4 lines

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.

Quoted 4 lines

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

Quoted 12 lines

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

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" <[email protected]>

Cc Alistair Francis <[email protected]>

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

package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch new file +36 -0

new file mode 100644
index 0000000..0d4e581
@@ -0,0 +1,36 @@
+From 2a310549aaeaba05f640ade43488bb893101ce4a Mon Sep 17 00:00:00 2001
+From: "Yann E. MORIN" <[email protected]>
+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" <[email protected]>
+---
+ 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
+

Signature · 1 line

2.7.4

Alistair, All,

On 2016-10-29 16:43 +0200, Yann E. MORIN spake thusly:

Quoted 11 lines

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" <[email protected]>

Cc Alistair Francis <[email protected]>

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

Quoted 48 lines

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

package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch new file +36 -1

new file mode 100644
index 0000000..0d4e581
@@ -0,0 +1,36 @@
+From 2a310549aaeaba05f640ade43488bb893101ce4a Mon Sep 17 00:00:00 2001
+From: "Yann E. MORIN" <[email protected]>
+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" <[email protected]>
+---
+ 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
+
--

Quoted 2 lines

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

Quoted 24 lines · Yann E. MORIN

Alistair, All,

On 2016-10-29 16:43 +0200, Yann E. MORIN spake thusly:

Quoted 11 lines

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" <[email protected]>

Cc Alistair Francis <[email protected]>

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

Quoted 1 line

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

Quoted 66 lines

Regards,
Yann E. MORIN.

Quoted 48 lines

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

package/xen/0002-xen-Rules.mk-fix-build-with-CFLAGS-from-environment.patch new file +36 -1

new file mode 100644
index 0000000..0d4e581
@@ -0,0 +1,36 @@
+From 2a310549aaeaba05f640ade43488bb893101ce4a Mon Sep 17 00:00:00 2001
+From: "Yann E. MORIN" <[email protected]>
+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" <[email protected]>
+---
+ 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
+
--

Quoted 2 lines

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

Quoted 27 lines · Alistair Francis

Quoted 25 lines · Yann E. MORIN

Alistair, All,

On 2016-10-29 16:43 +0200, Yann E. MORIN spake thusly:

Quoted 11 lines

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" <[email protected]>

Cc Alistair Francis <[email protected]>

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

Quoted 3 lines

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 <[email protected]>

Reviewed-by Alistair Francis <[email protected]>

Signed-off-by Alistair Francis <[email protected]>

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

package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch new file +10 -0

new file mode 100644
index 0000000..ca772dd
@@ -0,0 +1,26 @@
+From 234847440a5d3cf95540ea79f7a08d50cccfef73 Mon Sep 17 00:00:00 2001
+From: Alistair Francis <[email protected]>
+Date: Tue, 13 Sep 2016 10:48:31 -0700
+Subject: [PATCH] Remove hardcoded strict -Werror checking
+
+Signed-off-by: Alistair Francis <[email protected]>
+---
+ Config.mk | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+

package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch new file +6 -0

+ HOSTCFLAGS += -fno-strict-aliasing
+ 
+ DISTDIR     ?= $(XEN_ROOT)/dist
+-- 
+2.7.4
+

Quoted 1 line · Alistair Francis

Signed-off-by Alistair Francis <[email protected]>

Quoted 21 lines

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

package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch new file +10 -0

new file mode 100644
index 0000000..ca772dd
@@ -0,0 +1,26 @@
+From 234847440a5d3cf95540ea79f7a08d50cccfef73 Mon Sep 17 00:00:00 2001
+From: Alistair Francis <[email protected]>
+Date: Tue, 13 Sep 2016 10:48:31 -0700
+Subject: [PATCH] Remove hardcoded strict -Werror checking
+
+Signed-off-by: Alistair Francis <[email protected]>
+---
+ Config.mk | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+

package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch line 20

Quoted 10 lines

package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch new file +10 -0

+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

Quoted 7 lines

package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch new file +6 -0

+ HOSTCFLAGS += -fno-strict-aliasing
+ 
+ DISTDIR     ?= $(XEN_ROOT)/dist
+-- 
+2.7.4
+

Quoted 4 lines · Arnout Vandecappelle

Quoted 1 line · Alistair Francis

Signed-off-by Alistair Francis <[email protected]>

I forgot to mention before: the commit message should refer to the autobuilder
failures.

Quoted 31 lines

Quoted 31 lines

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

package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch new file +19 -0

new file mode 100644
index 0000000..ca772dd
@@ -0,0 +1,26 @@
+From 234847440a5d3cf95540ea79f7a08d50cccfef73 Mon Sep 17 00:00:00 2001
+From: Alistair Francis <[email protected]>
+Date: Tue, 13 Sep 2016 10:48:31 -0700
+Subject: [PATCH] Remove hardcoded strict -Werror checking
+
+Signed-off-by: Alistair Francis <[email protected]>
+---
+ 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

Quoted 8 lines

package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch line 20

Quoted 1 line

package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch new file +1 -0

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

Quoted 4 lines

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) <[email protected]>

and look into removing the -Wall if needed for other build failures.

Quoted 2 lines

Better still, work with upstream to find a solution.

That's still true of course :-)

Regards,
Arnout

Quoted 5 lines

Regards,
Arnout

Quoted 8 lines

package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch line 26

Quoted 7 lines

package/xen/0001-Remove-hardcoded-strict-Werror-checking.patch new file +6 -0

+ 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