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.
Attachment:
signature.asc
Description: PGP signature