7.4d4
2 July 2022 21:29
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.
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
7.4d4
4 July 2022 23:15
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.