Part of my problem is caused by trying to build each of the parts into Debian packages. It is much easier if I can use the standard libraries already provided in the Debian repositories.
I believe it is fine to compile against the Debian (and Ubuntu) libsodium so long as you add the following to your cabal.project.local file:
package cardano-crypto-praos flags: -external-libsodium-vrf
I don’t know how the cabal magic works, but I believe these lines somehow expose some extra functions so that your compiled cardano-node binary doesn’t need the custom IOG version of libsodium. In other words, it can run with only the standard libsodium. Probably the extra functions required are compiled in so they don’t need to be dynamically loaded???
If on the other hand, you build the custom IOG version of libsodium and compile cardano-node against that (IE: without those extra cabal.project.local magic lines), then that means you must also copy that custom version of libsodium to every machine you want to run your cardano-node binary.
I have now made some “libsodium23-iog” and “libsodium-dev-iog” packages using the IOG version of libsodium. I had to add a heap of extra symbols to the symbols file I stole form the standard Debian libsodium package so that the Debian package system can work out dependencies correctly. This is because IOG have added, or made available, many extra functions in libsodium which are not available in the Debian version of libsodium. If I now install my libsodium-dev-iog package and compile cardano-node against that then the Debian package manager will know that my custom libsodium23-iog package is a dependency for installing and running my new cardano-node debian package. Thus when I do “apt install cardano-node” the package manager will automatically also install my “libsodium23-iog” package as a dependency.
In other words, it is a bit of extra work to create custom versions of library deb packages if you don’t use the standard Debian/Ubuntu libraries.
This is also why I am trying to figure out why IOG is not using one of the later release versions of libsecp256k1. I really want to just use the standard Debian version of libsecp256k1 which is version 0.2.0 and is later than the git commit “ac83be33” specified by IOG. If anyone from IOG can tell me if version 0.2.0 is fine, I would be grateful. I actually compiled against that Debian version and it is running fine on all my relays and my block producer for a couple of weeks now.
It is worth a bit of pain to get things packaged correctly because then I can compile everything on a separate build machine and none of my running machines need to have any of the compiler or build chain software. Furthermore, the package manager then takes care of installs and upgrades which removes a lot of human error such as forgetting to remove old versions of binaries/libraries or setting up executable/library paths correctly. It is just much better to use your package manager to install, remove, and upgrade software.