| Message ID | 20180820165929.20741-1-fontaine.fabrice@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/1] zeromq: fix build on m68k_cf | expand |
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" == 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.
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)
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(+)