Update 1.35.0 on Testnet:error while loading shared libraries: libsecp256k1.so.0: cannot open shared object file: No such file or directory

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?

1 Like

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?:

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.

1 Like

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.

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?

1 Like

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.


@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 :frowning:

1 Like

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