Your message dated Wed, 22 Jul 2020 02:12:26 +0200
with message-id <[email protected]>
and subject line Re: Bug#830942: pdns: FTBFS on m68k and powerpcspe: missing
__atomic_{load,fetch_add}_8
has caused the Debian Bug report #830942,
regarding pdns: FTBFS on m68k and powerpcspe: missing
__atomic_{load,fetch_add}_8
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
830942: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830942
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: pdns
Version: 4.0.0-1
Severity: important
Justification: fails to build from source (but built successfully in the past)
The m68k and powerpcspe builds of pdns failed:
/bin/bash ../libtool --tag=CXX --mode=link m68k-linux-gnu-g++
-DSYSCONFDIR=\"/etc/powerdns\" -DPKGLIBDIR=\"/usr/lib/m68k-linux-gnu/pdns\"
-DLOCALSTATEDIR=\"/var/run\" -fPIE -DPIE -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
--param ssp-buffer-size=4 -fstack-protector -g -O2 -fstack-protector-strong
-Wformat -Werror=format-security -DPACKAGEVERSION='"4.0.0-1.Debian"'
-std=gnu++11 -pie -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z,relro -o
dumresp dnslabeltext.o dnsname.o dumresp.o logger.o misc.o statbag.o
unix_utility.o qtype.o
libtool: link: m68k-linux-gnu-g++ -DSYSCONFDIR=\"/etc/powerdns\"
-DPKGLIBDIR=\"/usr/lib/m68k-linux-gnu/pdns\" -DLOCALSTATEDIR=\"/var/run\" -fPIE
-DPIE -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 --param ssp-buffer-size=4
-fstack-protector -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -DPACKAGEVERSION=\"4.0.0-1.Debian\" -std=gnu++11 -pie
-pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,relro -o dumresp
dnslabeltext.o dnsname.o dumresp.o logger.o misc.o statbag.o unix_utility.o
qtype.o -pthread
dumresp.o: In function `std::__atomic_base<unsigned long
long>::load(std::memory_order) const':
/usr/include/c++/5/bits/atomic_base.h:396: undefined reference to
`__atomic_load_8'
/usr/include/c++/5/bits/atomic_base.h:396: undefined reference to
`__atomic_load_8'
/usr/include/c++/5/bits/atomic_base.h:396: undefined reference to
`__atomic_load_8'
/usr/include/c++/5/bits/atomic_base.h:396: undefined reference to
`__atomic_load_8'
/usr/include/c++/5/bits/atomic_base.h:396: undefined reference to
`__atomic_load_8'
dumresp.o:/usr/include/c++/5/bits/atomic_base.h:396: more undefined
references to `__atomic_load_8' follow
dumresp.o: In function `std::__atomic_base<unsigned long
long>::fetch_add(unsigned long long, std::memory_order)':
/usr/include/c++/5/bits/atomic_base.h:514: undefined reference to
`__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status
Makefile:2281: recipe for target 'dumresp' failed
make[5]: *** [dumresp] Error 1
Please try explicitly linking against -latomic, perhaps with
-Wl,--as-needed to avoid incurring a dependency on it on other
architectures.
Thanks!
--- End Message ---
--- Begin Message ---
Version: 4.3.0-2
* Aaron M. Ucko <[email protected]> [200722 00:11]:
> "Aaron M. Ucko" <[email protected]> writes:
>
> > Christian Hofstaedtler <[email protected]> writes:
> >
> >> Maybe you could chime in on the upstream discussion at [1] on how to
> >> get this past libtool in a working way?
> >
> > Oh, right, libtool wrangling. :-/ Thanks for getting the discussion
> > started; I'll take a look.
>
> Aha, the problem is that this as-needed -latomic request winds up
> *before* the object files that use symbols from it. Moving the relevant
> -Wl construct to LIBS should help. I'll comment upstream in a moment.
Given 4.3.0-2 builds successfully on m68k (can't see the powerpcspe
result), I'm closing this (for now?).
Chris
--- End Message ---
