What does ldd output for cardano-node version 1.35.0?

Staking & Delegation Operate a Stake Pool
1

Here is ldd output for my compiled version of cardano-node 1.35.0:

ldd /usr/bin/cardano-node 
	linux-vdso.so.1 (0x00007fff641f3000)
	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f3d6065a000)
	libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f3d605c7000)
	libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f3d602d3000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3d602b6000)
	libsodium.so.23 => /lib/x86_64-linux-gnu/libsodium.so.23 (0x00007f3d6025c000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3d6023a000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3d6022d000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3d60228000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3d60222000)
	libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f3d601a1000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3d5ffdc000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3d5fe98000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f3d5fe6e000)
	libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f3d5fd93000)
	liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f3d5fd70000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f3d5fc50000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3d60715000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f3d5fc2a000)

Note: I did compile libsecp256k1 library and install it on the compiling machine but it has been statically linked by my compiling environment and I am trying to figure out why. I am also trying to figure out if I have any other libraries statically linked which maybe shouldn’t be.

Can someone who has a compiled and working version of cardano-node 1.35.0 please provide the output of ldd command on their version? Please.

2 
 ldd /var/tmp/1.35.0/cardano-node
	linux-vdso.so.1 (0x00007ffeaaca4000)
	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f40b6cbc000)
	libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f40b6c29000)
	libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f40b6935000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f40b6918000)
	libsodium.so.23 => /usr/local/lib/libsodium.so.23 (0x00007f40b68b8000)
	libsecp256k1.so.0 => /lib/libsecp256k1.so.0 (0x00007f40b6793000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f40b676f000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f40b6764000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f40b675f000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f40b6759000)
	libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f40b66d8000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f40b6513000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f40b63cd000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f40b63a5000)
	libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f40b62ca000)
	liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f40b62a7000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f40b6187000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f40b6d79000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f40b615f000)

It’s on Debian 11.

1 Like
3

Thanks @georgem1976
So my only difference is:

libsecp256k1.so.0 => /lib/libsecp256k1.so.0 (0x00007f40b6793000)

I can’t figure out why the debian debuild process is statically linking that one. I have packaged libsecp256k1 myself rather than use the version in the debian 11 (bullseye) repositories because I got some error I can’t recall now. However, I even tried compiling cardano-node against a manually compiled and locally installed version of secp256k1 (exactly as IOG has outlined using “make install”). Static linking still occurred.

Thanks. Now I can focus a bit more knowing that it is only this libsecp256k1 library.