cmake .. Returns error libatomic not found
SatoriHoshiAiko opened this issue · comments
Hi I cannot install libmultiprocess
I am returned the error:
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/CapnProto/CapnProtoConfig.cmake:71 (message):
libatomic not found
Call Stack (most recent call first):
CMakeLists.txt:9 (find_package)
I have installed capnproto from master tree c++ here:
https://github.com/capnproto/capnproto/tree/master/c%2B%2B
using autoreconf -i && ./configure && make -j6 check && sudo make install
Running CMake .. on build directory still did not work.
I double checked libatomic-ops and installed from master tree at
https://github.com/ivmai/debian-libatomic-ops
I updated libstdc++ with sudo apt-get install libstdc++ and apt -fix-broken install for safe measure
I again ran for capnproto on master/capnproto/c++
autoreconf -i && ./configure && make -j6 check && sudo make install
to see if the reconfiguration would link libatomic
Again testing CMake .. on libmultiprocess/build I am returned:
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/CapnProto/CapnProtoConfig.cmake:71 (message):
libatomic not found
Call Stack (most recent call first):
CMakeLists.txt:9 (find_package)
Why is CMake not finding libatomic and connecting it for capnproto?
Under capnproto issues another user had a similar problem with Raspbian. In my case I am running Kali with Debian Bullseye repositories overtop. My system is well built with GNU libraries as well, and runs as a full fleshed out Debian distro inside a Kali. I am on linux x86_64.
In his case capnproto did not want to build at all, but it passes with all tests succeeded in my case, however it is not liking to configure with libatomic-ops, even though it is already installed.
Because of this the CMake for libmultiprocess cannot be done.
Just looking to set libmultiprocess in place for installing bitcoin and master tree using --enable-libmultiprocess for added compatibility in advance of future needs. I don't want to have to recomp[ile with enable multiprocess later on, it could be frustrating. I am aware that this is entirely to assist in the C++ libraries for compiling purposes only, and doesn't really have any major affect on bitcoin-core installation, but I would prefer using libmultiprocess with bitcoin for any compatibility issues post installation or with accessory uses.
I would appreciate the time looked into this.
Satori Hoshi
Thanks for reporting this. Few observations:
- It seems suspicious that libatomic is required because this seems to be an x86_64 build. I'd expect libatomic should only be required for non-x86 architectures like Raspberry Pi's.
- According to your capnproto install steps, I think capnproto should be installed in
/usr/local/lib
, but cmake is finding capnproto in/usr/lib/x86_64
. So I wonder if cmake is finding a prebuilt version of capnproto on your system (like a libcapnp-dev package) and ignoring the capnproto which you built and installed. You could try to uninstall the other package if there is one.
Suggestions:
- Since error is coming from /usr/lib/x86_64-linux-gnu/cmake/CapnProto/CapnProtoConfig.cmake line 71, do you think you could upload that file in a gist or paste line 71 and surrounding lines? This file is generated by
cmakethe capnproto build. Knowing what is happening line 71 would help narrow down what is causing this. - Can you look for a
/usr/local/lib/cmake/CapnProto/CapnProtoConfig.cmake
file? If it exists but CMake is not using it, you may be able to prioritize it by runningexport CMAKE_MODULE_PATH=/usr/local/lib/cmake
- Can you say what operating system & architecture you are building on so I can try to reproduce the problem? Any other build logs you want to upload would also be helpful
I had indeed a source version installed and an apt repository installed. I checked into the conflict and it was the apt repository that was being prioritized.
For some reason sudo apt install libcapnp-dev capnproto on my Kali (+ Debian Bullseye Repositories) auto installs with a request for atomic.
Architecture x86_64 as mentioned. On an AMD VPS. Debian is Bullseye, Kali is x86_64
I looked further and found that my GCC GNU, which is well updated and smoothly synced before this, I have gcc-11 gcc-12 both on my system now. It did not have libatomic. I added sudo apt-get install libatomic1, and it sources from:
https://packages.debian.org/bullseye/libatomic1
This alone doesn't solve the issue and the sudo apt install libcapnp-dev capnproto adds to the CapnProtoConfig.cmake to look for atomic library.
This is an issue with capnproto imho. Or the apt-repository version at least configures to look for it.
I tried exporting to the location you mentioned and it didn't prioritize how one would have hoped.
Final solution was to uninstall both. And reinstall only the repository version of capnproto at
https://github.com/capnproto/capnproto/tree/master/c%2B%2B
I uninstalled with sudo make uninstall
Reinstalled with sudo autoreconf -i && ./configure && make -j6 check && sudo make install
With only the source repository version of capnproto, the CapnProtoConfig.cmake does not show in the /usr/lib/x86_64-linux-gnu/cmake as you expected. This is where apt places it. Source repository directs to usr/local/lib/cmake as you also.. expected.
The CapnProtoConfig.cmake this time is not including the flags looking for atomic library as the other version did.
Upon running cmake .. in build for libmultiprocess it has succeeded.
I appreciate the input from your end, you most definitely helped direct my attention to the right places. You may consider updating documentation to include this issue with installation of capnproto via sudo apt install libcapnp-dev capnproto
And recommend installing the dependency from source, in case anyone encounters a similar issue of the apt repository configuring incorrectly.
It was very minimal installation instructions and usually the apt versions consider in advance any errors a person would have on their system architecture. Agains this is actually an issue with Debian bullseye apt and capnproto, but from here it could be helpful to note that capnproto is best build from source tree, to avoid any issues.
It's a side comment that really is locating in advance any errors with a CapnProto installation. Over there they have very minimal support and there is very little documentation online to document or guide a person that has a replica issue, and their source tree of course is already correct, but the apt tree is the origin of the issue before this.
Installation instructions:
If sudo apt install libcapnp-dev capnproto causes any issues during installation:
-ADD-
You my sudo apt remove and download capnproto from source with
git clone https://github.com/capnproto/capnproto.git
cd ./capnproto/c++
sudo autoreconf -i && ./configure && make -j6 check && make install
then proceed to cd into /libmultiprocess
-END-
mkdir build
cd build
cmake ..
make
make check # Optionally build and run tests
make install
Small side note, I had to start with a fresh clone of libmultiprocess in order for cmake to run correctly. But it ran fine after doing so.
Thx again
SatoriHoshiAiko
Wow, what a journey. I was able to reproduce the issue on debian by just trying to use build libmultiprocess against current libcapnp-dev package. Error is
-- Looking for __atomic_load_8 in atomic
-- Looking for __atomic_load_8 in atomic - not found
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/CapnProto/CapnProtoConfig.cmake:71 (message):
libatomic not found
from
if (yes) # WITH_LIBATOMIC
include(CheckLibraryExists)
check_library_exists(atomic __atomic_load_8 "" FOUND_LIBATOMIC)
if (FOUND_LIBATOMIC)
list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
else()
message(FATAL_ERROR "libatomic not found")
endif()
endif()
which seems to come from this debian patch https://sources.debian.org/patches/capnproto/0.9.1-4/07_libatomic.patch/ unnecessarily requiring libatomic.
The error seems to happen because /usr/lib/x86_64-linux-gnu/libatomic.so.1.2.0
from https://packages.debian.org/sid/libatomic1 doesn't have an __atomic_load_8
symbol, but I'm not sure how WITH_LIBATOMIC
autoconf variable would have been yes in that case during the capnproto package build
Will look into this more and try to find a workaround. I'd prefer the build just work and not have to update the instructions to work around it.
The following patch seems to function as a workaround:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 55c2a6b..7b01db3 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -6,6 +6,7 @@ cmake_minimum_required(VERSION 3.0)
project("Libmultiprocess" CXX)
include(CMakePushCheckState)
include(CheckCXXSourceCompiles)
+set(FOUND_LIBATOMIC TRUE)
find_package(CapnProto REQUIRED)
find_package(Threads REQUIRED)
I started to debug the debian package to see why it is setting WITH_LIBATOMIC to yes, and I think maybe it is doing the right thing, because the test program referencing the __atomic_load_8
symbol is about to link with -latomic
. And readelf shows the symbol in the library:
# readelf -Ws /usr/lib/x86_64-linux-gnu/libatomic.so.1 | grep __atomic_load_8
62: 00000000000035d0 8 FUNC GLOBAL DEFAULT 13 __atomic_load_8@@LIBATOMIC_1.0
So the question maybe is why doesn't cmake find the symbol in the library
Figured out the root cause. It is a bug in the debian package caused by a limitation of cmake. Cmake fails to find the __atomic_load_8
symbol even though it exists. Running cmake with cmake --debug-trycompile ..
shows:
Building CXX object CMakeFiles/cmTC_6fce7.dir/CheckFunctionExists.cxx.o
/usr/bin/c++ -DCHECK_FUNCTION_EXISTS=__atomic_load_8 -o CMakeFiles/cmTC_6fce7.dir/CheckFunctionExists.cxx.o -c /root/libmultiprocess/build/CMakeFiles/CheckLibraryExists/CheckFunctionExists.cxx
<command-line>: error: new declaration ‘char __atomic_load_8()’ ambiguates built-in declaration ‘long unsigned int __atomic_load_8(const volatile void*, int)’ [-fpermissive]
<command-line>: note: in definition of macro ‘CHECK_FUNCTION_EXISTS’
/root/libmultiprocess/build/CMakeFiles/CheckLibraryExists/CheckFunctionExists.cxx: In function ‘int main(int, char**)’:
/root/libmultiprocess/build/CMakeFiles/CheckLibraryExists/CheckFunctionExists.cxx:17:24: error: too few arguments to function ‘long unsigned int __atomic_load_8(const volatile void*, int)’
17 | CHECK_FUNCTION_EXISTS();
gmake[1]: *** [CMakeFiles/cmTC_6fce7.dir/build.make:78: CMakeFiles/cmTC_6fce7.dir/CheckFunctionExists.cxx.o] Error 1
Looking at the CheckFunctionExists.cxx
test program shows it can't compile because it tries to declare the __atomic_load_8
function in the global C++ namespace, and this conflicts with the compiler built in defintion. Autoconf avoids this problem by declaring the function inside a namespace conftest
c++ namespace, and fixing the symbol name by declaring it extern "C"
So autoconf is able to find the symbol and cmake is unable to find it. So the cmake code debian added in https://sources.debian.org/patches/capnproto/0.9.1-4/07_libatomic.patch/ is broken, and probably needs to be fixed to detect the the libatomic library another way, or cmake check_library_exists
function needs to be improved and maybe use the same namespace trick that autoconf uses.
Either way I think hardcoding set(FOUND_LIBATOMIC TRUE)
in the CMakeLists.txt file might be the easiest workaround, and maybe some of @SatoriHoshiAiko's documentation suggestions would help as well. Will follow up soon with some fix
Related: aws/aws-sdk-cpp#1243
So the cmake code debian added in https://sources.debian.org/patches/capnproto/0.9.1-4/07_libatomic.patch/ is broken...
The updated link: https://sources.debian.org/patches/capnproto/0.9.2-2/07_libatomic.patch/
I started encountering this error after upgrading from Ubuntu 22.04 to 23.04. However, I didn't try right before the upgrade, so perhaps that's unrelated.
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so (found version "3.0.8") found components: Crypto SSL
-- Looking for __atomic_load_8 in atomic
-- Looking for __atomic_load_8 in atomic - not found
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/CapnProto/CapnProtoConfig.cmake:71 (message):
libatomic not found
Call Stack (most recent call first):
CMakeLists.txt:23 (find_package)
Using capnproto 0.9.2-2.
I ended up building 0.10.4 from source.
Either way I think hardcoding
set(FOUND_LIBATOMIC TRUE)
in the CMakeLists.txt file might be the easiest workaround, and maybe some of @SatoriHoshiAiko's documentation suggestions would help as well. Will follow up soon with some fix
Another possible solution is to enable C language:
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -4,7 +4,7 @@
cmake_minimum_required(VERSION 3.8)
-project("Libmultiprocess" CXX)
+project("Libmultiprocess")
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED YES)
Hello. I run into this problem while building another package, however I need to use system-provided CapnProto. I'm going to report this issue to Ubuntu, but to avoid duplicated issue, have anyone here reported this to Ubuntu or Debian yet?