Bug 444547 - Build failure on Linux Clang targets with usage of atomics
Summary: Build failure on Linux Clang targets with usage of atomics
Status: REPORTED
Alias: None
Product: extra-cmake-modules
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Manjaro Linux
: NOR normal
Target Milestone: ---
Assignee: ecm-bugs-null@kde.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-28 14:41 UTC by sh_zam
Modified: 2022-03-17 14:52 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sh_zam 2021-10-28 14:41:48 UTC
SUMMARY

The sources we use to check if the atomic libraries are present or not, by default with the compiler are incomplete. Which results in the assumption that the library is present at compile time, when the full version actually isn't. 

This results in linking error: 

ld.lld: error: undefined symbol: __atomic_is_lock_free

STEPS TO REPRODUCE
1. Use clang (x86_64-pc-linux-gnu)
2. Compile https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/master/modules/CheckAtomic.cmake#L44-50 without linking atomic
3. Compile https://invent.kde.org/-/snippets/1924 again without linking atomic

OBSERVED RESULT

Things work in the first case (step 2), but fail in second (step 3). Hence, misdirecting the compiler.

ADDITIONAL INFORMATION

clang version: 12.0.1
Target: x86_64-pc-linux-gnu
Comment 1 sh_zam 2021-10-28 14:44:06 UTC
Git commit 0b755beaa1fdba03d38f887b93a15a58fc0830c7 by Sharaf Zaman.
Committed on 28/10/2021 at 14:42.
Pushed by szaman into branch 'master'.

Fix build on linux clang targets

In CheckAtomic.cmake we include is_lock_free because these routines
don't seem to be included in the compiler's "simple atomics". This
triggers a failure in clang toolchain, forcing it to link libatomic.

Resulting in error: ld.lld: error: undefined symbol: __atomic_is_lock_free
Related: bug 444247

M  +1    -0    cmake/modules/CheckAtomic.cmake
M  +2    -4    libs/image/CMakeLists.txt

https://invent.kde.org/graphics/krita/commit/0b755beaa1fdba03d38f887b93a15a58fc0830c7
Comment 2 Alex Fan 2022-02-14 02:21:41 UTC
Can we include the ```HAVE_CXX_ATOMICS_WITH_LIB OR HAVE_CXX_ATOMICS64_WITH_LIB``` part in 5.1.0 and possibly also 5.0.x? Currently as I see, this patch only exists in master branch.
The reason is not clang specific, but on platforms like riscv that have builtin 64bits atomics while lacks anything smaller, HAVE_CXX_ATOMICS_WITHOUT_LIB is FALSE and HAVE_CXX_ATOMICS64_WITHOUT_LIB is TRUE. So the condition  ``` if(NOT HAVE_CXX_ATOMICS_WITHOUT_LIB) if(NOT HAVE_CXX_ATOMICS64_WITHOUT_LIB)``` still doesn't link atomic though checkatomic.cmake sets these value correctly.
Comment 3 amyspark 2022-03-17 14:52:21 UTC
Git commit 1418085400e95b5a13218e98d318333dd591e8b9 by L. E. Segovia, on behalf of Sharaf Zaman.
Committed on 17/03/2022 at 14:50.
Pushed by lsegovia into branch 'krita/5.0'.

Fix build on linux clang targets

In CheckAtomic.cmake we include is_lock_free because these routines
don't seem to be included in the compiler's "simple atomics". This
triggers a failure in clang toolchain, forcing it to link libatomic.

Resulting in error: ld.lld: error: undefined symbol: __atomic_is_lock_free
Related: bug 444247
(cherry picked from commit 0b755beaa1fdba03d38f887b93a15a58fc0830c7)

M  +1    -0    cmake/modules/CheckAtomic.cmake
M  +2    -4    libs/image/CMakeLists.txt

https://invent.kde.org/graphics/krita/commit/1418085400e95b5a13218e98d318333dd591e8b9