Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Revert "Fix build error on riscv64 by linking libatomic"
This reverts commit 10c277c. Whether `-latomic` needs to be linked or not depends on the used toolchain, not the architecture of the platform we build for. In my case I'm building on a riscv64 system using the LLVM toolchain, so there's not even a `-latomic` to link against. But the current logic tries to link `-latomic` anyway, resulting in a build failure. The correct way to detect whether the used toolchain needs to link `-latomic` explicitly in order to use `__atomic_fetch_and_1` seems to be `AC_SEARCH_LIBS`. This was 1.) introduced in e0de0d9 ("link with -latomic if needed") 2.) wrongly removed in commit 10c277c ("Fix build error on riscv64 by linking libatomic"). 3.) reinstantiated in commit 18ec3b9 ("link with -latomic if needed (again ...)") The build log[1] referenced in the PR[2] that introduced the unconditional linking of `-latomic` on riscv64 shows that the build error happened with version 2.0.14, but the commit introducing the usage of `AC_SEARCH_LIBS` was merged after that: $ git --no-pager tag --contains e0de0d9 v2.0.15 v2.0.16 So it looks like e0de0d9 ("link with -latomic if needed") fixed the problem for both scenarios and 10c277c ("Fix build error on riscv64 by linking libatomic") wasn't necessary at all after it. [1] https://buildd.debian.org/status/fetch.php?pkg=numactl&arch=riscv64&ver=2.0.14-3&stamp=1632275973&raw=0 [2] #131 Signed-off-by: Marvin Schmidt <marv@exherbo.org>
- Loading branch information