[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: -latomics vs riscv64

On 31 Jan 2022, at 08:37, Mathieu Malaterre <malat@debian.org> wrote:
> [cc me please]
> Dear riscv64 porters,
> I am trying to get JPEG-XL to compile on riscv64. After reading of:
> * https://github.com/riscv-collab/riscv-gcc/issues/12
> I am under the impression that the black magic to get -latomic passed
> on the linker line is handled somewhere in gcc spec file.
> This also seems to be the case, per my reading of the log file at:
> * https://buildd.debian.org/status/fetch.php?pkg=jpeg-xl&arch=riscv64&ver=0.7.0%7Egit20220120.0647da4%2Bds-3&stamp=1643404075&raw=0
> The following c++11 code (1):
> ```
> #include <atomic>
> #include <cstdint>
> std::atomic<uint64_t> num (0);
> int main() {
>  uint64_t i = num.load(std::memory_order_relaxed);
>  return 0;
> }
> ```
> seems to compile and link nicely without the need for an explicit
> `-latomic`. However somewhere later during the compilation, I receive
> an error that:
> /usr/bin/ld: libjxl_dec.so.0.7.0: undefined reference to `__atomic_fetch_and_1'
> /usr/bin/ld: libjxl_dec.so.0.7.0: undefined reference to `__atomic_fetch_or_1'
> So now it seems that I need an explicit `-latomic`
> Could someone please share his knowledge on -latomic on riscv64 Debian
> arch ? Please note that the above c++11 code rightfully fails to
> compile on armel/mipsel and powerpc which allow the buildsystem to
> detect the need for an explicit `-latomic` being added by cmake.

RISC-V only has 32-bit and 64-bit atomic instructions. GCC is supposed
to convert smaller atomics to those larger ones via masking and
shifting like LLVM, but it’s a known bug that it does not. This means
anything that wants to use atomics on 1-byte or 2-byte types needs
-latomic, but not 4-byte or 8-byte (though it does no harm).


Reply to: