CMAKE_CXX_LINK_FLAGS (-latomic) lead to failed builds on armhf Raspberry Pi OS about ecal HOT 10 OPEN

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!

from ecal.

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?

from ecal.

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.

from ecal.

@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.

from ecal.

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?

from ecal.

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.

from ecal.

@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.

from ecal.

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?

from ecal.

Maybe use CMAKE_REQUIRED_LIBRARIES then?

list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")

from ecal.

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

from ecal.