Avoid statically linking glibc

[pepeiborra]

As discussed in #2431 we shouldn't be linking glibc statically. Unfortunately it is not easy to select which C libraries are linked statically, so this change disables static linking altogether. This means that the binaries will have a bunch of runtime dependencies:

$ ldd hls
	linux-vdso.so.1 (0x00007fff50bcf000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f408a70d000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f408a6f3000)
	libtinfo.so.5 => /usr/lib/libtinfo.so.5 (0x00007f408a68f000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007f408a684000)
	libutil.so.1 => /usr/lib/libutil.so.1 (0x00007f408a67f000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f408a678000)
	libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007f408a5d6000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f408a40a000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007f408a2c6000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f408a768000)

The resulting binaries will fail to work in any of the dependencies above are missing or too old, e.g. in Linux systems older than the CI system (Ubuntu LTS 18), or in Linux systems with non-standard lib paths like NixOS.

The next step will be switching to binaries with statically linked musl in place of glibc. This can be done easily by building HLS in an Alpine Linux distribution. In fact the Gitlab CI already builds alpine binaries, so in principle all that needs to do is update the packaging scripts to reuse those binaries.

[pepeiborra]

Binaries build successfully but, as expected, don't work out of the box on an older CentOS 8 system:

╰─>$ ./haskell-language-server-9.0.1 
./haskell-language-server-9.0.1: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

[jneira]

I guessthis has been superseded by #2463 and can be closed