[Bug] Latest SourceMod build fails to load on Debian 10

[waldotf]

Help us help you

• [X] I have checked that my issue doesn't exist yet.
• [X] I have tried my absolute best to reduce the problem-space and have provided the absolute smallest test-case possible.
• [X] I can always reproduce the issue with the provided description below.

Environment

• Operating System version: Debian Buster (from i386/debian:buster)
• Game/AppID (with version if applicable): TF2/440
• Current SourceMod version: 1.11
• Current SourceMod snapshot: 6940
• Current Metamod: Source snapshot: 1153
• [X] I have updated SourceMod to the latest version and it still happens. (6940)
• [X] I have updated SourceMod to the latest snapshot and it still happens. (7060)
• [ ] I have updated SourceMM to the latest snapshot and it still happens.

Description

I run a network of TF2 servers in Debian Buster containers and have them configured to check for Metamod and SourceMod updates on reboot. As of the most recent stable build, they fail to load SourceMod with the following error:

meta load sourcemod
Failed to load plugin addons/sourcemod/bin/sourcemod_mm (/lib/i386-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /srv/srcds/tf/addons/sourcemod/bin/sourcemod.2.tf2.so)).

The latest version of libc6 available on this OS is 2.28, and I can't easily patch that without upgrading the OS (which has its own problems for my setup). Build 6940 seems more like a refactor than an intentional compatibility-breaking update, so I think this is an oversight, possibly due to a new build environment. If this is deliberate, rationale for the change would be appreciated.

MetaMod successfully loads another plugin (Stripper 1.2.2) and behaves as expected.

Problematic Code (or Steps to Reproduce)

Attempt to load SourceMod 6940 on a system for which:

# ldd --version
ldd (Debian GLIBC 2.28-10+deb10u2) 2.28
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

[dvander]

I'll see what I can do about this, I'm willing to move the 1.11 builder down to Debian 9 for older distros if it comes to that. For 1.12+ we're trying to enable C++17, and very likely libstdc++ requires newer libc, and there's nothing we can do about that.

Note that Debian 10 is no longer getting security updates and is EOL in a few months. You probably want to upgrade.

[waldotf]

Thanks. I definitely get that Debian 10 is on the way out, but it's not officially EOL until July so I figured I had some more runway.

[dvander]

I've moved the 1.11 builder back down to Debian 9. That seems reasonable as it's a stable branch, and we usually freeze build environments for those. Unfortunately that does mean keeping the VM alive solely for this one build.

For 1.12,I want libstdc++-9 which has std::filesystem support. That's only available in Debian 11, which has glibc-2.34. Otherwise, I have to reimplement std::filesystem in AMTL which is waste of time.

There's a few random alternative routes, that I'd rather not do, but might be possible in the future:

• Switch to libc++ for games that can statically link it. Might introduce weird compatibility bugs. Low effort.
• Compile our own libstdc++-9 for Debian 9. Medium effort.
• Compile our own libc and libstdc++, then add them to the repository as prebuilts. High effort. But we'd get hermetic builds out of it.

[pet0ruk]

To me it seems reasonable to require a higher glibc in a major version change from 1.11 to 1.12. Thanks for reverting this for the stable branch.

[dvander]

Verified that this works now.