libmultiprocess icon indicating copy to clipboard operation
libmultiprocess copied to clipboard

cmake .. Returns error libatomic not found

Open SatoriHoshiAiko opened this issue 2 years ago • 10 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.

https://github.com/capnproto/capnproto/issues/1448

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

SatoriHoshiAiko avatar May 22 '22 08:05 SatoriHoshiAiko

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 ~cmake~ the 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 running export 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

ryanofsky avatar May 22 '22 13:05 ryanofsky

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

SatoriHoshiAiko avatar May 23 '22 05:05 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.

ryanofsky avatar May 23 '22 19:05 ryanofsky

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

ryanofsky avatar May 23 '22 20:05 ryanofsky

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

ryanofsky avatar May 23 '22 21:05 ryanofsky

Related: https://github.com/aws/aws-sdk-cpp/pull/1243

hebasto avatar Sep 07 '22 21:09 hebasto

Well the workaround for me was simple.

Not use the Debian package version, and just build from the capnproto source.

I have a tendency to try every available option when I have an issue, to ensure it is fully corrected. I can confirm what you are seeing is correct, the Debian apt repository has this error.

Once I saw that I checked the same config.cmake of the capnproto source version, it was not there.

Building from their source resolved the issue and libmultitool built with no issue.

I think this is the most direct solution. Except for perhaps posting the issue to where the Debian package is built and notifying that libatomic should not be unilaterally requested.

But to me it was just uninstall one (Debian) and use the other (CapnProto git source). Problem solved.

SatoriHoshiAiko

On Mon, May 23, 2022 at 1:58 PM Ryan Ofsky @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/chaincodelabs/libmultiprocess/issues/68#issuecomment-1135083069, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWUI5A7MLKJH3JCGBNTIDVLVLPPPVANCNFSM5WTASUSQ . You are receiving this because you modified the open/close state.Message ID: @.***>

SatoriHoshiAiko avatar Oct 11 '22 08:10 SatoriHoshiAiko

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/

hebasto avatar Feb 15 '23 10:02 hebasto

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.

Sjors avatar Apr 28 '23 17:04 Sjors

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)
 

hebasto avatar May 10 '23 14:05 hebasto