Dear all,
Cardano-Node 1.35.0 on Relay-Server is running, but the Core-Node doesn’t start because of:
error while loading shared libraries: libsecp256k1.so.0: cannot open shared object file: No such file or directory
I checked already the PATH Variable and LD_LIBRARY_PATH Variable but it remains the same.
Any ideas?
Did you compile the cardano-node version 1.35.0 yourself?
Did you install the bitcoin library libsecp256k1 when compiling version 1.35.0 as specified here?:
https://github.com/input-output-hk/cardano-node/blob/master/doc/getting-started/install.md/
What is confusing me though is why your compiled version is asking for this shared library when mine is not.
When I compiled version 1.35.0, I also compiled and installed libsecp256k1. However, I believe this library was statically linked in to the cardano-node binary.
When I run cardano-node version 1.35.0 on another machine the libsecp256k1 library is not required for it to run.
Yes I followed the mentioned instructions on github and repeated it once.
I get always the same message, that the libsecp256k1 cannot be found. It’s located in /usr/local/lib and I changed already $PATH and $LD_LIBRARY_PATH
Added both paths?
Add the following to your ~/.bashrc file and source it (or re-open the terminal):
export LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH"
Yes, I added both paths.
For the entry in .bashrc I would guess, that
export LD_LIBRARY_PATH=/usr/local/lib is better, because echo $LD_LIBRARY_PATH gives /usr/local/lib:/usr/local/lib: with the other syntax, but I tried both.
Yes, I reopened my shell several times.
After
sudo ln -s /usr/local/lib/libsecp256k1.so.0 /usr/lib/libsecp256k1.so.0
the node started.
It’s from electrum-docs/libsecp256k1-linux.rst at master · spesmilo/electrum-docs · GitHub
I have compiled libsecp256k1 myself and then used this library to compile cardano-node version 1.35.0. My compiled version appears to run correctly.
I am building the cardano-node as a debian package and the debian tools do some automagic stuff that I don’t properly understand. I suspect that these tools could be producing my cardano-node binary with its libraries statically linked when maybe they shouldn’t be.
As I said, my compiled cardano-node binary works properly, but I don’t need libsecp256k1 installed on the running machine. I only need this library on the compiling machine.
Can anyone else confirm this?
what do you mean? the guide is 100% valid, you will add the KES inside the script after u will create them (next chapter)
ok, that’s my fault!
@Alexd1985 are you able to confirm this is expected behaviour? Will your compiled cardano-node 1.35.0 run without libsecp256k1 library installed?
If everything is working well then shoukd be fine, I did not tested yet
Hi @Alexd1985 : My compiled version 1.35.0 is running fine. However, I wonder if I shouldn’t be having libsecp256k1 statically linked in. The reason I ask is because the initial poster @solydar said he got this error when starting his 1.35.0 node:
Which seems to indicate that his libsecp256k1 is dynamically linked and therefore this library needs to be installed on the computer running the node.
TBH I don’t know I haven’t time to test it
Installing libsecp256k1 or libsodium in an air-gapped, offline environment would be a bit of a pain.
CHG
@Alexd1985 would you please do a ldd on your cardano-node binary and post the output. This is what mine says:
ldd /usr/bin/cardano-node
linux-vdso.so.1 (0x00007ffdc13bc000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f3ac0051000)
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f3abffbe000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f3abfcca000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3abfcad000)
libsodium.so.23 => /lib/x86_64-linux-gnu/libsodium.so.23 (0x00007f3abfc4d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3abfc2b000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3abfc1e000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3abfc19000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3abfc13000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f3abfb92000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3abf9cd000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3abf889000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f3abf85f000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f3abf784000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f3abf761000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f3abf641000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3ac010c000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f3abf61b000)
Note that libsecp256k1 is not listed in my output because it has been statically linked for some reason. I am trying to see if there are any other libraries that my binary has statically linked.
I did not updated yet 
anyone here seen any issue installing llvm-12 (it was in the prereq installs for the coincashew update 1.35 here: Upgrading to Cardano 1.35.0 for nodes created manually/using Coincashew )
edit: may not be required, did not see it on the cardano git instructions
I had an almost similar issue. I had installed both libsodium and libsecp256k1 as indicated in the iohk guide. After doing cabal build all it failed with the same error. I thought it could be that both libraries files paths may not be ‘loaded’ and so I restarted my Fedora machine.
After trying the build again it worked perfectly!
On my debian (bullseye) system I have libllvm11 and have successfully compiled version 1.35.0:
dpkg --get-selections | grep llvm
libllvm11:amd64 install