ARM (Raspberry Pi4) build fails: link error undefined reference to `__atomic_load_8'

[imiron13]

Preliminary checks

• [X] I've checked that there aren't other open issues on the same topic.
• [X] I've checked that this issue is reproducible on the latest snapshot build.

Platform

Linux

Describe the bug

I tried to build the game (0.9.17) for Raspberry pi 4 (Raspberry Pi OS, Debian based) following the this instruction. It fails on a linking stage with the following error:

/usr/bin/ld: ../engine/libengine.a(audio.o): in function `(anonymous namespace)::musicFinished()':
audio.cpp:(.text+0x160): undefined reference to `__atomic_load_8'
/usr/bin/ld: ../engine/libengine.a(audio.o): in function `(anonymous namespace)::playMusic(unsigned long long, Music::PlaybackMode)':
audio.cpp:(.text+0x129c): undefined reference to `__atomic_fetch_add_8'
/usr/bin/ld: audio.cpp:(.text+0x14c0): undefined reference to `__atomic_fetch_add_8'
/usr/bin/ld: ../engine/libengine.a(audio.o): in function `(anonymous namespace)::MusicRestartManager::executeTask()':
audio.cpp:(.text+0x18dc): undefined reference to `__atomic_load_8'
/usr/bin/ld: ../engine/libengine.a(audio.o): in function `Music::Stop()':
audio.cpp:(.text+0x2e64): undefined reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status

Compiler: g++ (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110

I managed to finish the build by adding '-latomic' linker flag. I am not familiar with CMake so I just restarted linking with extra flag using a shell command. Need to add this flag in the build system in order to support ARM/Raspberry Pi build.

See also: https://github.com/ihhub/fheroes2/issues/4353

BTW, it works smoothly on Raspberry Pi 4. Haven't noticed any issues playing for ~30 mins. Quite enjoyable.

Save file

N/A

Additional info

No response

[undef21]

Try this:

export LDFLAGS=-latomic
make

[imiron13]

Thanks for the quick reply. Looks like the same issue this way.. UPD: I do see that -latomic appears in the command line now. Not sure why it did not help. I think all I did to build it successfully previously was adding that flag. Need to double-check.

[imiron13]

@undef21 , LDFLAGS line added this option at the beginning of the command line. But kooks like -latomic should go after object file names in command line. Does not work: g++ -latomic -pthread agg.o ... ai_normal_spell.o ../engine/libengine.a ../thirdparty/libsmacker/libsmacker.a -lSDL2_mixer -lSDL2 -lz -o fheroes2 This one works: g++ -pthread agg.o ... ai_normal_spell.o ../engine/libengine.a ../thirdparty/libsmacker/libsmacker.a -lSDL2_mixer -lSDL2 -lz -latomic -o fheroes2

[undef21]

Hm, my RPi 1 build the game a little slower than you but building was successfull. Could you please do make clean before rebuild?

lnk: fheroes2
g++ -latomic -pthread army_bar.o ... ai_normal_spell.o ../engine/libengine.a ../thirdparty/libsmacker/libsmacker.a -lSDL2_mixer -lSDL2  -lz -o fheroes2

[imiron13]

On my board even with clean build I'm getting this error when -latomic is at the beginning.

[imiron13]

This one works for me: export LDFLAGS="-Wl,--start-group -latomic" Picked it from here: https://stackoverflow.com/questions/45135/why-does-the-order-in-which-libraries-are-linked-sometimes-cause-errors-in-gcc

[oleg-derevenetz]

I reclassified this as a request for improvement, because there are a 100500 different architectures, and we can't support everything. We reliably support only those architectures for which we build the binaries ourselves.

[undef21]

I checked building on Debian 10 armel, armhf and arm64. This issue reproduced only on armel in my case. Looks like it's heavily depends on platform, gcc version and other factors, so I think it's the task for maintainers to add additional flags for a particular system.

[ihhub]

We simply cannot and won't support many platforms as highlighted by @oleg-derevenetz . Our scope and possibilities are within GitHub actions and we cannot build any ARM stuff right now.

[Laserlicht]

As a small addition: if you only want to play, then you can also take the flatpak version. I tested it yesterday on the Rasperry Pi. Runs without problems. But only ARM64.

[ihhub]

Closing this issue as this is beyond the scope of this project based on the discussion above.