zeromq: fix build on m68k_cf
PATCH 1/1 zeromq: fix build on m68k_cf
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
--- package/zeromq/zeromq.mk | 6 ++++++ 1 file changed, 6 insertions(+)
package/zeromq/zeromq.mk +6 -0
@@ -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)
Signature · 1 line
2.14.1
PATCH 1/1 zeromq: fix build on m68k_cf
Hello,
package/zeromq/zeromq.mk ZEROMQ_CONF_ENV = libzmq_cv_sock_cloexec=yes \ · line 30
Quoted 5 lines · Fabrice Fontaine
package/zeromq/zeromq.mk +5
-0+# 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
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/1 zeromq: fix build on m68k_cf
Quoted 19 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hello,
package/zeromq/zeromq.mk ZEROMQ_CONF_ENV = libzmq_cv_sock_cloexec=yes \ · line 30
Quoted 5 lines · Fabrice Fontaine
package/zeromq/zeromq.mk +5
-0+# 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" +endifI'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
Quoted 8 lines
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.
Signature · 1 line
Bye, Peter Korsgaard