Riscv compilation encounters a tbss error

[HowToExpect]

/home/f133/tina5.0-f133/out/toolchain/riscv64-glibc-gcc-thead_20200702/bin/../lib/gcc/riscv64-unknown-linux-gnu/8.1.0/../../../../riscv64-unknown-linux-gnu/bin/ld: ./app: section .tbss lma 0xdf8c0 adjusted to 0xdf8d0

moodycamel::ConcurrentQueue queueMouseData;
queueMouseData.enqueue(10);

As long as I call enqueue, there will be a compilation error

./app: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

During runtime, an error will occur stating that the libatomic.so cannot be found

[cameron314]

I don't think the .tbss adjustment is an error?

For libatomic.so, it sounds like you're missing some runtime dependencies, or perhaps it's a toolchain installation issue?

[HowToExpect]

The "Pseudo" Lock-Free Operation Due to the Lack of 'A' Extensions
RISC-V employs a modular instruction set. If your target chip is a simplified microcontroller (e.g., only supporting RV32I or RV32EC, without implementing hardware-level 'A' atomic instruction extensions):

The C++ compiler will automatically fall back, calling the underlying libatomic library to simulate atomic operations.

This simulation is typically implemented using internal mutexes. This causes the originally "lock-free" queue to degenerate into a locked queue, completely defeating its design purpose and introducing significant interrupt latency risks.

[cameron314]

Oh, I see. You may want to find a different queue optimized for this architecture.

Which operations are emulated? The queue implementation uses several, not all of which are on the hot path. The important one is fetch_add (64 bit by default but this can be adjusted).

In any case, libatomic should be available at runtime if the compiler is pulling it in.