Build of 14.06 fails on armv7 due to libatomic not being linked

Beginners
1

I am working on getting a buildroot system (for OpenWrt) working on an armv7 device. Part of it is llvm 14.06. For the most part, the build is picking up on the need to explicitly link libatomic on this platform. However when llvm-ar is being linked, it fails to add -latomic and the build fails.

Also I don’t know if it’s OpenWrt’s buildroot system or LLVM, but when LLVM is being built it ignores the system CFLAGS and LDFLAGS environment variables. Unfortunately the nature of this particular buildroot system makes it extremely difficult to make any changes as it untars from downloaded sources every time it runs. Which means that to get it to build on this platform I had to take the step of creating shell scripts for gcc/g++ that added in -latomic.

Two questions: 1) is the llvm-ar libatomic issue on armv7 a known issue? 2) does LLVM’s build system actually ignore CFLAGS/LDFLAGS? If so, what is the correct way to pass in compiler/linker flags that I want it to honor?

Thanks.

2

What host compiler are you using? There’s a known issue in older versions of LLVM that makes it generate calls to libatomic when it shouldn’t; see ⚙ D123950 Look through calls to std::addressof to compute pointer alignment. , which was merged for LLVM 15. We cherry-picked a workaround for building LLVM with LLVM to LLVM 14, though; see Backport "Force GHashCell to be 8-byte-aligned." to LLVM 14 · Issue #54962 · llvm/llvm-project · GitHub .

I don’t know of any issue that specifically affects llvm-ar. In general, the LLVM build system should add libatomic to the link line when it’s necessary; see llvm/cmake/modules/CheckAtomic.cmake .

You should be able to force flags onto the link line using the CMake variables CMAKE_C_FLAGS/CMAKE_CXX_FLAGS. Not sure whether the CMake scripts respect CFLAGS/CXXFLAGS off the top of my head.

3

Thank-you for the quick reply.

gcc 11.2.0

It’s not LLVM that was used here, unless it was used earlier in the process to generate libLLVM-14.so. The problem occurred during the compilation of llvm-ar, but I see that the actual location of the atomic call was in libLLVM-14.so.

/mnt/bulk/devel/openwrt/staging_dir/host/bin/g++ -O2 -I/mnt/bulk/devel/openwrt/staging_dir/host/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -DNDEBUG -L/mnt/bulk/devel/openwrt/staging_dir/host/lib    -Wl,-rpath-link,/mnt/bulk/devel/openwrt/build_dir/host/llvm-project-14.0.6.src/build/./lib  -Wl,--gc-sections tools/llvm-ar/CMakeFiles/llvm-ar.dir/llvm-ar.cpp.o -o bin/llvm-ar  -Wl,-rpath,"\$ORIGIN/../lib"  lib/libLLVM-14.so && :
/usr/bin/ld: lib/libLLVM-14.so: undefined reference to `__atomic_fetch_add_8@LIBATOMIC_1.0'
collect2: error: ld returned 1 exit status

Thank-you, I’ll test out adding -latomic to the CMake vars.

4

If your host compiler is gcc, the LLVM bug should be irrelevant.

It looks like you’re using LLVM_LINK_LLVM_DYLIB. There’s a bug specific to that configuration; see ⚙ D132799 Make sure libLLVM users link with libatomic if needed . (I don’t think the fix was cherry-picked to LLVM 15; it will be in LLVM 16.)

1 Like
5

It wasn’t, no, but thank-you for the link. I was able to take the patch and put it in OpenWrt’s build system. Version 15.0.7 successfully builds on ARM 32 now.