Fix some build/install problems

[godotalgorithm]

I have two outstanding build problems to solve. First, the glibc compatibility library was broken by the glibc version updates in Ubuntu 22, so I need to use an older image until this is fixed. Second, the static build option was broken by changes over the last year and needs to be repaired.

Status

• [x] Ready for merge

[codecov-commenter]

Codecov Report

Merging #146 (65bc4ab) into main (1cdaa88) will not change coverage. The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@           Coverage Diff           @@
##             main     #146   +/-   ##
=======================================
  Coverage   66.67%   66.67%           
=======================================
  Files         331      331           
  Lines       73714    73714           
=======================================
  Hits        49152    49152           
  Misses      24562    24562           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[godotalgorithm]

There doesn't seem to be a problem per se with the static build option, it's just not common to have static versions of system libraries available. The two development environments that I was testing the feature in did not have the necessary files available and failed when trying to link the executables. I've added a warning message about CMake not being able to check for the availability of these libraries in the pre-build phase.

[susilehtola]

There doesn't seem to be a problem per se with the static build option, it's just not common to have static versions of system libraries available.

No, the issue is that the statically built executable crashes.

[godotalgorithm]

There doesn't seem to be a problem per se with the static build option, it's just not common to have static versions of system libraries available.

No, the issue is that the statically built executable crashes.

But does some other program (e.g. a trivial stub) with the same library dependencies statically build just fine, or is this just a generic inability to statically build functioning executables on a system? I can't really probe the issue further right now because I don't have easy access to any development environments where I can build a fully static executable (unless I build libm & libc myself). My suspicion is that all library dependencies need to be locally rebuilt with consistent static linking of all system libraries for this to work. When I was trying this out, CMake was grabbing static versions of OpenBLAS libraries that it found, and I certainly wasn't building those myself.

Do you have any perspective on how common fully static builds of executables even are on Linux? This does imply static linking of libm and libc (presumably glibc on Linux, I guess?), which I thought was generally not recommended.

[susilehtola]

On Fedora it's possible to build static executables, you just need to have the glibc-static and openblas-static packages installed. Debian/Ubuntu likewise have static libm and libc in the libc6-dev package, see e.g. https://packages.ubuntu.com/kinetic/amd64/libc6-dev/filelist

Static builds are not used in the distributions themselves for maintainability reasons (static linkage means whenever you update a package you have to rebuild all dependent packages!) but they are probably used by many companies to deploy code...