How to build 1.35.0 from source on Ubuntu 22.04

After reading about the issues of other operators regarding 1.35.0 I tried my own luck with it. And, after some fiddling around, I’ve finished compilation. I’ve yet to try the binaries, but there you go:

  • I upgraded to Ubuntu 22.04 beforehand. This not necessary - and looking at it afterwards it made things even more complicated. I.e., if you don’t insist on upgrading (for several reasons) don’t do it!
  • Install secp256k1: cd to your preferred source directory and use the following commands
git clone https://github.com/bitcoin-core/secp256k1.git
cd secp256k1
git reset --hard ac83be33d0956faf6b7f61a60ab524ef7d6a473a
./autogen.sh
./configure --prefix=/usr/local --enable-module-schnorrsig --enable-experimental
make
make check
sudo make install

If you are on an Intel (AMD64) platform you don’t need clang - it also compiles with gcc.
That would have been it on an 21.xx Ubuntu release - as others also figured out. But you’ll have to continue if you’re on 22.04:

  • If you have libssl-dev installed you’ll have to de-install it (because it is libssl3 and not libssl1):
sudo apt-get --purge remove libssl-dev
  • The next steps are downloading libssl1 packages and installing them:
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.1l-1ubuntu1.5_amd64.deb
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl/libssl-dev_1.1.1l-1ubuntu1.5_amd64.deb
sudo dpkg -i libssl1.1_1.1.1l-1ubuntu1.5_amd64.deb
sudo dpkg -i libssl-dev_1.1.1l-1ubuntu1.5_amd64.deb
  • Now you can continue with the usual steps to compile the source with cabal.

Feedback is welcome - especially when it comes to running the binaries. I’m waiting for the official go-ahead for mainnet before starting them on mainnet.

5 Likes

Yesterday evening I started the binaries on a relay system. Works like charm since then. But note that you’ll have to explicitly add the LD_LIBRARY_PATH to the start script otherwise the node software won’t load the installed libraries. For cncli I used a wrapper script instead of providing the path to the node:

cat cardano-node-wrapper.sh 
#!/bin/bash
export LD_LIBRARY_PATH=/home/cardano/.local/lib
export PKG_CONFIG_PATH=/home/cardano/.local/lib/pkgconfig
/home/cardano/.local/bin/cardano-node $@

As you can see I have the libraries in ~/.local/lib instead of /usr/local/lib

cncli sendtip can the be called with:

cncli sendtip --cardano-node $HOME/tools/cardano-node-wrapper.sh --config $HOME/mainnet-node/pooltool.json

When I compiled cardano-node version 1.35.0 I built it as a deb package and this build system applies some extra switches to gcc which I don’t fully understand. It seems that my secp256k1 library is statically linked and therefore is not required to be installed on my running machine.

Which libraries do you have in that directory? Did you install the libssl1 libraries manually rather than via the dpkg tool on the running machine?

Or are you talking about the secp256k1 library? Does your running machine require the secp256k1 library to be installed or is your binary like mine with this library statically linked?

Here is what ldd shows for my cardano-node binary:

ldd /usr/bin/cardano-node 
        linux-vdso.so.1 (0x00007ffe12ff3000)
        libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f4d2eeb8000)
        libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f4d2ee25000)
        libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f4d2eb31000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4d2eb14000)
        libsodium.so.23 => /usr/local/lib/libsodium.so.23 (0x00007f4d2eab4000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4d2ea92000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4d2ea85000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f4d2ea80000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4d2ea7a000)
        libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f4d2e9f9000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4d2e834000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4d2e6f0000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f4d2e6c6000)
        libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f4d2e5eb000)
        liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f4d2e5c8000)
        libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f4d2e4a8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4d2ef8b000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f4d2e482000)

I’m not a fan of statically linking libs. That’s why I’ve

	libsodium.so.23 => /home/cardano/.local/lib/libsodium.so.23 
	libsecp256k1.so.0 => /home/cardano/.local/lib/libsecp256k1.so.0 

in my cardano-node binary (ldd output). As you can see I’m also not a big fan of storing local libs and execs in global dirs. But your mileage may vary. But seeing libsodium dynamically linked and libsecp256k1 statically makes me wonder as of why.

However, there are many roads to setup a system. And people should implement whatever they like. Just wanted to give some hints about pitfalls, and solutions.

Regarding the libssl question - I was using the deb packages with dpkg like I wrote above.

1 Like

Btw. from looking into the list of issues it pretty much looks like we’ll get a 1.35.1 release before hardfork. The current release has still some bugs like showing the wrong slots for leadership-schedule and similar stuff. I.e. nothing really bad, but nasty for using cardano-cli.

1 Like

I am not sure how I achieved libsecp256k1 being statically linked. I have compiled libsecp256k1 both as a debian package and also using the manual method specified with the library installed locally. In both cases when I compiled cardano-node I ended up with libsecp256k1 statically linked.

Yes. But I am having the debian package system manage them by creating debian packages for libsodium23 (IOG version), libsecp256k1, cardano-node, cncli, and everything else I compile. Then I can just compile once and “apt dist-upgrade” on every one of my machines. The libraries, executables and scripts I am using are all updated easily. The debian packaging system makes everything so much easier…

If only I understood how to make the packages fully and what all the switches for the debuild process mean… I am definitely not a qualified debian package maintainer.

Do you have any other libraries (apart from libsecp256k1) in your ldd output for cardano-node that I don’t have? (In comparing the ldd output in my previous post.)?

As an alternative to the wrapper script, one can also define the additional environment variables in the service definition as well:

[Unit]
Description=CNCLI Sendtip
After=multi-user.target
[Service]
User=cardano
Group=cardano
Environment=LD_LIBRARY_PATH=/home/cardano/.local/lib
Environment=PKG_CONFIG_PATH=/home/cardano/.local/lib/pkgconfig
Type=simple
Restart=always
RestartSec=25
LimitNOFILE=131072
ExecStart=/home/cardano/.cargo/bin/cncli sendtip --cardano-node /home/cardano/.local/bin/cardano-node --config /home/cardano/mainnet-node/pooltool.json
KillSignal=SIGINT
SuccessExitStatus=143
StandardOutput=journal
StandardError=journal
SyslogIdentifier=cncli-sendtip
[Install]
WantedBy=multi-user.target

You’ll have to change paths according to your system of course.