Quoting Johannes Schauer Marin Rodrigues (2025-02-10 10:48:35)
> Quoting Simon Richter (2025-01-17 11:43:39)
> > In my own packages, I check if libatomic exists, and if it does, I
> > unconditionally link if I use any atomics. I also check if the linker 
> > accepts
> > --push-flags, if it does I generate a
> > -Wl,--push-flags,--as-needed,-latomic,--pop-flags sequence, if not, the
> > unconditional link will generate dpkg-shlibdeps warnings about unnecessary
> > linking on amd64, but that's better than failing on other platforms.
> 
> thank you for your help! I now patched vcmi with snippets like this:
> 
> if (CMAKE_LIBRARY_ARCHITECTURE STREQUAL "arm-linux-gnueabi")
>         target_link_options(vcmi PRIVATE 
> "-Wl,--push-flags,--as-needed,-latomic,--pop-flags")
> endif()
> 
> I understand from the other mails that this architecture-check is not even
> needed and that --as-needed will let the linker do the right thing. I still
> like to special-case the only arch where this seems to be needed. I gave up on
> hoping that onetbb fixes it as neither upstream nor the Debian bug show any
> activity, so I'm patching my own package instead.
> 
> But then I get the complaint:
> 
> /usr/bin/ld: unrecognized option '--push-flags'
> 
> You probably meant --push-state and --pop-state instead?

probably related to how to correctly link against atomic with CMake I have
another follow-up question. Adding the above target_link_options() to the
relevant shared libraries indeed does the trick. But for my package vcmi, I
also seem to need it for an executable. Unfortunately, when I apply the same
recipe, I get this:

[100%] Linking CXX executable ../bin/vcmiclient
cd /build/reproducible-path/vcmi-1.6.5+dfsg/obj-arm-linux-gnueabi/clientapp && 
/usr/bin/cmake -E cmake_link_script CMakeFiles/vcmiclient.dir/link.txt 
--verbose=1
/usr/bin/c++ -g -O2 
-ffile-prefix-map=/build/reproducible-path/vcmi-1.6.5+dfsg=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Wpointer-arith 
-Wuninitialized -Wmismatched-tags -Wno-unused-parameter -Wno-switch 
-Wno-reorder -Wno-sign-compare -Wno-varargs -Wl,-z,relro -Wl,-z,now 
-Wl,--push-state,--as-needed,-latomic,--pop-state 
-Wl,--dependency-file=CMakeFiles/vcmiclient.dir/link.d 
CMakeFiles/vcmiclient.dir/StdInc.cpp.o 
CMakeFiles/vcmiclient.dir/EntryPoint.cpp.o -o ../bin/vcmiclient  
-Wl,-rpath,"\$ORIGIN::::::::::::::::::::::::" ../bin/libvcmiclientcommon.a 
../bin/libvcmiservercommon.a ../bin/libvcmi.so 
/usr/lib/arm-linux-gnueabi/libminizip.so /usr/lib/arm-linux-gnueabi/libz.so 
/usr/lib/arm-linux-gnueabi/libtbb.so.12.14 -ldl -lrt 
/usr/lib/arm-linux-gnueabi/libboost_filesystem.so.1.83.0 
/usr/lib/arm-linux-gnueabi/libboost_program_options.so.1.83.0 
/usr/lib/arm-linux-gnueabi/libboost_locale.so.1.83.0 
/usr/lib/arm-linux-gnueabi/libboost_thread.so.1.83.0 
/usr/lib/arm-linux-gnueabi/libboost_atomic.so.1.83.0 
/usr/lib/arm-linux-gnueabi/libboost_chrono.so.1.83.0 
/usr/lib/arm-linux-gnueabi/libboost_date_time.so.1.83.0 
/usr/lib/arm-linux-gnueabi/libSDL2_image.so 
/usr/lib/arm-linux-gnueabi/libSDL2_mixer.so 
/usr/lib/arm-linux-gnueabi/libSDL2_ttf.so /usr/lib/arm-linux-gnueabi/libSDL2.so 
/usr/lib/arm-linux-gnueabi/libavutil.so 
/usr/lib/arm-linux-gnueabi/libswscale.so 
/usr/lib/arm-linux-gnueabi/libavformat.so 
/usr/lib/arm-linux-gnueabi/libavcodec.so 
/usr/lib/arm-linux-gnueabi/libswresample.so
/usr/bin/ld: ../bin/libvcmiclientcommon.a(SDLImageScaler.cpp.o): undefined 
reference to symbol '__atomic_fetch_add_8@@LIBATOMIC_1.0'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/14/libatomic.so: error adding 
symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

I suspect that the problem is the order in which the -latomic is added to the
linker flags? Because if instead of target_link_options() with push and
pop-state I just use

    target_link_libraries(vcmiclient PRIVATE atomic)

Then that will add a -latomic right after ../bin/libvcmiclientcommon.a and then
the build succeeds. Here is the relevant CMakeLists.txt:

https://sources.debian.org/src/vcmi/1.6.5%2Bdfsg-1/clientapp/CMakeLists.txt/#L38

So what is the canonical way to achieve the desired result with CMake? Will I
instead have to globally set LDFLAGS="-Wl,--as-needed"?

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature

Reply via email to