add glibc 2.17 binary build for older enterprise Linux support

[marcpope]

The current binary releases require glibc >= 2.31, which excludes:

• RHEL/Rocky/Alma 8 (glibc 2.28) — supported until 2029
• RHEL/CentOS 7 (glibc 2.17) — still in use in many production environments
• Ubuntu 18.04 (glibc 2.27) — still common in production
• Debian 10 (glibc 2.28) — still in LTS support

Would you consider adding a glibc 2.17 build target to CI?

I've confirmed Borg 1.4.3 builds and runs correctly on CentOS 7 / Alma & Rocky 8 with the following adjustments:

• Add -std=c99 to CFLAGS (required for GCC 4.8's default C89 mode)
• Build Python 3.10 and OpenSSL 1.1.1 locally for the build environment
• Use PyInstaller to produce the single-file binary

The resulting binary works on all glibc 2.17+ systems, which would cover the entire enterprise Linux ecosystem from CentOS 7 through current releases.

A single glibc 2.17 build would provide backward compatibility without requiring multiple build targets.

Example build using glibc 2.1.7 which covers many more older Linux.
https://github.com/marcpope/borgbackupserver/tree/main/public/borg/1.4.3

[ThomasWaldmann]

The oldest Linux build system we have on github CI is ubuntu 22.04 and we use that.

What you can do is to use an older release of borg, which was still built on the vagrant VM, like release 1.4.1 or 1.2.9.

[marcpope]

Even 1.2.9 is compiled with (glibc231). Red Hat Variants (Rocky / Alma 8) use glibc228. So they won't run. From what I can tell, I need to use < 1.2 on those operating systems to use official binaries.

[ThomasWaldmann]

borg 1.2.9 "linuxold" is glibc 2.24.

[ThomasWaldmann]

I am closing this as not planned:

• if users use borg on such old systems, they can also use an old borg release (either one available as a package from their dist or one we had build on an old build system)
• we can't do such "old glibc" builds on github CI
• these old OSes do not even have Python 3.10, which we require for current releases