[Buildroot] [PATCH 1/1] zeromq: fix build on m68k_cf

[Buildroot] [PATCH 1/1] zeromq: fix build on m68k_cf

[Fabrice Fontaine]

An internal compiler error is raised on m68k_cf at dwarf2cfi.c:2752 in
connect_traces. Error can be fixed by adding -fno-defer-pop, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864

Fixes:
 - http://autobuild.buildroot.net/results/dad241acbe59b1c5a24a0a2f3da6b12a553aec84

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
 package/zeromq/zeromq.mk | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/package/zeromq/zeromq.mk b/package/zeromq/zeromq.mk
index 8273cad763..4b25c7d678 100644
--- a/package/zeromq/zeromq.mk
+++ b/package/zeromq/zeromq.mk
@@ -23,6 +23,12 @@ ZEROMQ_CONF_ENV = libzmq_cv_sock_cloexec=yes \
 	libzmq_cv_tcp_keepidle=yes \
 	libzmq_cv_tcp_keepintvl=yes
 
+# Internal error, aborting at dwarf2cfi.c:2752 in connect_traces
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864
+ifeq ($(BR2_m68k_cf),y)
+ZEROMQ_CONF_OPTS += CXXFLAGS="$(TARGET_CXXFLAGS) -fno-defer-pop"
+endif
+
 # Only tools/curve_keygen.c needs this, but it doesn't hurt to pass it
 # for the rest of the build as well (which automatically includes stdc++).
 ifeq ($(BR2_STATIC_LIBS),y)
-- 
2.14.1

[Buildroot] [PATCH 1/1] zeromq: fix build on m68k_cf

[Thomas Petazzoni]

Hello,

On Mon, 20 Aug 2018 18:59:29 +0200, Fabrice Fontaine wrote:

> +# Internal error, aborting at dwarf2cfi.c:2752 in connect_traces
> +# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864
> +ifeq ($(BR2_m68k_cf),y)
> +ZEROMQ_CONF_OPTS += CXXFLAGS="$(TARGET_CXXFLAGS) -fno-defer-pop"
> +endif

I've applied, but what bothers me is that we will never notice if/when
this workaround can be removed. Perhaps we should make such workarounds
depend on the gcc version, like this:

ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_9):$(BR2_m68k_cf),:y)
...
endif

This way, when we start using gcc 9.x, the workaround is no longer
applied. Either the bug is fixed, and we never see a build failure
again. Or the bug is not fixed, we noticed via autobuilder failure, and
extend the workaround to gcc 10.x.

Not sure what others think about this. OTOH, this is just about m68k
coldfire, maybe we don't care. But it's code that would probably stay
forever in BR.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/1] zeromq: fix build on m68k_cf

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

 > Hello,
 > On Mon, 20 Aug 2018 18:59:29 +0200, Fabrice Fontaine wrote:

 >> +# Internal error, aborting at dwarf2cfi.c:2752 in connect_traces
 >> +# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864
 >> +ifeq ($(BR2_m68k_cf),y)
 >> +ZEROMQ_CONF_OPTS += CXXFLAGS="$(TARGET_CXXFLAGS) -fno-defer-pop"
 >> +endif

 > I've applied, but what bothers me is that we will never notice if/when
 > this workaround can be removed. Perhaps we should make such workarounds
 > depend on the gcc version, like this:

 > ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_9):$(BR2_m68k_cf),:y)
 > ...
 > endif

 > This way, when we start using gcc 9.x, the workaround is no longer
 > applied. Either the bug is fixed, and we never see a build failure
 > again. Or the bug is not fixed, we noticed via autobuilder failure, and
 > extend the workaround to gcc 10.x.

 > Not sure what others think about this. OTOH, this is just about m68k
 > coldfire, maybe we don't care. But it's code that would probably stay
 > forever in BR.

I agree that it isn't super important here, but I like it! It's a great
way to verify if all the various workarounds are still needed when the
gcc version is bumped, and this only happens fairly rarely - So the
extra noise from this is pretty low.

-- 
Bye, Peter Korsgaard