CMAKE_CXX_LINK_FLAGS (-latomic) lead to failed builds on armhf Raspberry Pi OS

[jheeks]

Problem Description

When building ecal on armhf platform there is error:

Linking CXX executable ../../../bin/ecal_sys
/usr/bin/ld: ../sys_core/libsys_core.a(ecal_sys_monitor.cpp.o): undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/12/libatomic.so: error adding symbols: DSO missing from command line

Basically this problem is partly addressed in https://github.com/eclipse-ecal/ecal/blob/210d2367c9ec9adfac344a2a1acd39b16b38b87d/CMakeLists.txt#L61-L64 but the used cmake variable CMAKE_CXX_LINK_FLAGS is only applied for linking executables and not for libraries. As far as I understand, the variable CMAKE_CXX_STANDARD_LIBRARIES should be used instead, which will be applied for executables and libraries.

How to reproduce

Build ecal on an armhf SW platform e. g. I use Raspberry Pi 5 with Raspberry Pi OS Bookworm 32Bit. This might be confusing because the Pi 5 is of course an ARM64 HW platform using an ARM64 Linux kernel. But when using a 32bit root file system, then it behaves as an armhf SW platform.

How did you get eCAL?

Custom Build / Built from source

Environment

• eCal v5.12.1 and probably earlier versions
• Raspberry Pi OS Bookworm 32Bit, which is based on Debian Bookworm 32Bit
• cmake version 3.25.1
• gcc (Raspbian 12.2.0-14+rpi1) 12.2.0
• GNU ld (GNU Binutils for Raspbian) 2.40

eCAL System Information

No response

[FlorianReimold]

Hi @jheeks

I don't have a native arm plattform available for testing. But did you test it out (I mean the CMAKE_CXX_STANDARD_LIBRARIES)? Does it work?

[jheeks]

Yes, the mentioned change works on my armhf setup. I had short discussion with @hannemn and we wondered that the GitHub action seems to build for armhf without error.

[hannemn]

@jheeks actually meant the PPA build of armhf artefacts where the debuild toolchain is used. We were wondering if debuild automatically adds certain entries to the LDFLAGS environment variable by default when the compiling respectively linking step is performed on an armhf platform by cmake.

[KerstinKeller]

I think probably the best place to add this would be in custom toolchain files. Maybe the builds do have toolchain files which are then passed to CMake.

Another idea to handle this could be a custom target like CMake's threads::threads which links to pthread where it is necessary.

Maybe we should create an "atomic::atomic" target which links to atomic where necessary, and doesn't do anything where it isn't necessary? Maybe this is better than global linker flags?

[jheeks]

I have now tested the ecal build on a Raspberry Pi 4 with Ubuntu 22.04 (32-bit) and there is no linker error. The instructions on https://eclipse-ecal.github.io/ecal/development/building_ecal_from_source.html state that only Ubuntu LTS versions are supported for ecal builds from source on Linux. Means that my build try on Debian is not expected to be supported.

[FlorianReimold]

Here is the PPA buildlog of Ubuntu 22.04 Jammy for armhf:

https://launchpadlibrarian.net/694551122/buildlog_ubuntu-jammy-armhf.ecal_5.12.1-1ppa1~jammy_BUILDING.txt.gz

The cmake step displays

-- Performing Test ATOMIC_IS_BUILTIN
-- Performing Test ATOMIC_IS_BUILTIN - Success

It does not look like debuild added additional link flags, probably because I actively try to prevent it from doing that.

@jheeks Yes, we can only test eCAL on a final amount of Linux distributions. The infinite amount of available distributions prevent us from testing on all of them 😉 But only because we don't actively test on Debian Bookwork / Raspberry PI OS that doesn't mean that we wouldn't accept solutions for issues on those operating systems!

[KerstinKeller]

@jheeks I was wondering also if you are using a specific cmake toolchain file, and what exactily is in that file. The CMake documentation clearly states that CMAKE_CXX_STANDARD_LIBRARIES should not be set from project code.

Also I am looking closely at the error you encountered, is it possible that you print the complete command line for linking the object? This stackoverflow question suggests that something regarding the ordering of the arguments could be wrong.

[jheeks]

I do not use a toolchain file. I let cmake choose the host's toolchain. I just call cmake as suggested in the build for Ubuntu instructions

I looked up the failing command from the generated Makefile. It is: cd /home/heeks/git/ecal/_build/app/sys/sys_cli && /usr/bin/cmake -E cmake_link_script CMakeFiles/sys.dir/link.txt --verbose= With the lengthy link.txt It starts with /usr/bin/c++ -O3 -DNDEBUG -latomic and I think the -latomic is too early in the option list. It should be at least after the -o option. Or better at the very end. I manually moved it to the end and confirmed that linking is OK then for this part.

But why is cmake placing it wrong?

[FlorianReimold]

Maybe use CMAKE_REQUIRED_LIBRARIES then?

list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")

[jheeks]

list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")

I tried this, but:

• this does not fix the problem
• atomic is not added to the link.txt at all