On 2024-04-09, at 15:24:28 +0100, Jeremy Sowden wrote: > On 2024-03-30, at 02:03:57 +0500, Andrey Rakhmatullin wrote: > > Source: maildir-utils > > Version: 1.10.8-2 > > Severity: serious > > Tags: ftbfs > > > > https://buildd.debian.org/status/fetch.php?pkg=maildir-utils&arch=armel&ver=1.10.8-2%2Bb2&stamp=1711722478&raw=0 > > > > /usr/bin/ld: lib/index/libmu-index.a.p/mu-indexer.cc.o: in function > > `std::__atomic_base<long long>::store(long long, std::memory_order)': > > /usr/include/c++/13/bits/atomic_base.h:481:(.text+0xb14): undefined > > reference > > to `__atomic_store_8' > > /usr/bin/ld: lib/index/libmu-index.a.p/mu-indexer.cc.o: in function > > `std::__atomic_base<long long>::load(std::memory_order) const': > > /usr/include/c++/13/bits/atomic_base.h:505:(.text+0x1384): undefined > > reference > > to `__atomic_load_8' > > This is a 64-bit time_t bug. Will investigate.
gcc includes a library, libatomic.so, which supplies implementations of
atomic operations which cannot be implemented by native instructions.
On armel, this is required for 64 bit types:
$ cat test.cc
#include <atomic>
#include <iostream>
using namespace std;
int
main(void)
{
atomic_llong x(0);
long long y = 123;
x.store(y);
cout << x << endl;
}
$ g++ test.cc -o test
/usr/bin/ld: /tmp/ccVWAQDN.o: in function `main':
test.cc:(.text+0xe0): undefined reference to `__atomic_store_8'
/usr/bin/ld: /tmp/ccVWAQDN.o: in function `std::__atomic_base<long
long>::operator long long() const':
test.cc:(.text._ZNKSt13__atomic_baseIxEcvxEv[_ZNKSt13__atomic_baseIxEcvxEv]+0x98):
undefined reference to `__atomic_load_8'
collect2: error: ld returned 1 exit status
$ g++ test.cc -o test -latomic
$ ./test
123
Thus it is now required for 64-bit `time_t`.
This doesn't appear to be documented anywhere apart from other bug
reports. May be worth broaching with upstream.
J.
signature.asc
Description: PGP signature
