feat: add static builds presets

[nenkoru]

Closes #938

I finally made it, took a lot of experimentation. Used Act but I couldn't reproduce an issue where CMAKE tries to regenerate the build folder after forcing libpthread.a to be linked.
Also yeah, I could not normally force libpthread.a to be linked, so this ugly hack of using sed had to be issued. Also I couldn't reproduce this behaviour on 22.04 jammy when building manually.

[nenkoru]

At the end these static builds still use static openssl, so I thought it would be a good idea to just replace the release artificats to just be these static builds.

[scareything]

At the end these static builds still use static openssl, so I thought it would be a good idea to just replace the release artificats to just be these static builds.

Actually we've been talking about going in the other direction and use more of the distro-provided shared libraries for the release builds. The only reason we specifically link openssl statically is because we want the release binaries to run on ubuntu 20, but ubuntu 20 only provides a very old version (libssl.so.1.1) which a) we don't want to link against, and b) is not available on more current bistros.

So we'd like to keep the existing Linux release binaries as they are, and add -static variants of the Linux builds to the releases for this PR. To do this we'd need new entries to the matrix in cmake.yml (like I think you had done before), and they would use ubuntu-22.04 runners to avoid the dlopen build issue that you encountered when linking tlsuv.

Does this make sense? Let me know if I can help. I could make a PR against your fork with the changes I;m thinking of if you permit it.

[nenkoru]

At the end these static builds still use static openssl, so I thought it would be a good idea to just replace the release artificats to just be these static builds.

Actually we've been talking about going in the other direction and use more of the distro-provided shared libraries for the release builds. The only reason we specifically link openssl statically is because we want the release binaries to run on ubuntu 20, but ubuntu 20 only provides a very old version (libssl.so.1.1) which a) we don't want to link against, and b) is not available on more current bistros.

So we'd like to keep the existing Linux release binaries as they are, and add -static variants of the Linux builds to the releases for this PR. To do this we'd need new entries to the matrix in cmake.yml (like I think you had done before), and they would use ubuntu-22.04 runners to avoid the dlopen build issue that you encountered when linking tlsuv.

Does this make sense? Let me know if I can help. I could make a PR against your fork with the changes I;m thinking of if you permit it.

Alright, I see.
Not a problem, feel free to create another PR, just link the issue to it!
Thank you!

[scareything]

Moving to #949, on the release-1.x branch