Add support for building libclang targeting older versions of glibc

[PathogenDavid]

Currently we built our native components using Ubuntu 18.04 (the oldest in-support version of Ubuntu supported by GitHub Actions) so that our binary can be used on Linux systems utilizing glibc 2.27 or later.

However, glibc 2.27 is not actually all that old. For instance, CentOS 7 (in support until June 2024) still uses glibc 2.17 and Debian 9 (in support until June 2022) uses 2.24.

Rokas offered some solutions here: MochiLibraries/Biohazrd#155 (reply in thread)

The "easy" solution is probably to create a self-hosted GitHub Actions runner on CentOS or whatever the least common denominator is. Not a fan of this since it means more ongoing maintenance.

We could possibly set up a chroot or CentOS/whatever that is downloaded by CI.

The harder but better solution is to use this project to force libclang to be built against an older version of glibc: https://github.com/wheybags/glibc_version_header
It's not totally clear how involved this will be. It's pretty easy for a C app, but C++ poses some unique issues noted in the readme.

Another possibility not mentioned by Rokas is using a Docker image of CentOS/whatever for building. The x64 CentOS 7 image is "only" 72.57 MB. That's a little fat, but considering it's actually smaller than libclang its self is (which is kinda depressing) maybe that's not so bad.

One final possibility is using musl libc instead of glibc. This is what sccache does, not sure if it's practical for libclang or not.

Looking at the official binary distributions of LLVM: It seems that for x64 they're distributing separate binaries for each Ubuntu LTS as well as SLES. For ARM64 it appears they're just building a single binary distribution targeting an unspecified version of glibc. The separate binaries for x64 might just be a historical artifact, might be worth looking into how they're building that ARM64 distribution.

[PathogenDavid]

We should also check up on the implicit dependencies we picked up since they could be a source of problems as well:

pathogendavid@lovebuntu:~/Projects/InfectedLibraries/Biohazrd/bin/Debug-AnyCPU/TempConsoleApp/runtimes/linux-x64/native$ ldd libclang-pathogen.so
	linux-vdso.so.1 (0x00007ffee2dcf000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fedc5cfb000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fedc5cdf000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fedc5cd4000)
	libtinfo.so.5 => not found
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fedc5cb1000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fedc5b62000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fedc597e000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fedc5963000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fedc5771000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fedcbdb1000)

(Note that in particular, libtinfo5 was not present on my Ubuntu Desktop 20.04 install.)

[PathogenDavid]

Our ARM64 native components are currently built on Ubuntu 20.04 which is arguably excessively restrictive since it targets glibc 2.31, which corresponds to Ubuntu 20.04+, Debian 11+, Fedora 31+, and RHEL 9 Beta+.

[PathogenDavid]

Because I lost it, mentioning Python manylinux as an option or inspiration for this: https://github.com/pypa/manylinux

Also .NET 8 will target Ubuntu 16.04 / RHEL 8: dotnet/core#8133 (comment)

Also relevant: dotnet/runtime#69361