fails to load with undefined symbol: g_bUpdateStringTokenDatabase

[facerend-a11y]

addons/multiaddonmanager/bin/multiaddonmanager.so fails to load with undefined symbol: g_bUpdateStringTokenDatabase on the CS2 engine build that shipped ~July 9-10, 2026 (engine reports as 1.41.6.9/14169).
This is the same exact symbol Metamod itself was missing right after this update — meaning the engine update removed/changed something both plugins depend on.
Metamod's dev branch has already been rebuilt to handle it (working build: 2.0.0-dev+1403, commit 26c03fa), but MultiAddonManager hasn't yet.
I've confirmed this isn't a stale-download problem on my end — both the latest same-day GitHub Actions CI artifact and the official v1.5.1 release (published ~12 hours after the engine update) are byte-for-byte identical (matching md5sum) to the build that's already failing.
So there's currently no build anywhere, official or CI, that's actually been recompiled against this engine version.

[xen-000]

Are you sure everything is actually updated? Including your server? The latest release works on my server and I haven't heard from anyone else about your issue.

[facerend-a11y]

Thanks for checking fair question, and I wanted to rule out my own setup being the issue before pushing back further.
Confirmed environment:

CS2 engine: 1.41.6.9/14169 (build 10847, public branch), just re-verified live via status.
Metamod: 2.0.0-dev+1403 (needed its own dev-snapshot update to load on this engine at all — the stock release hit its own separate undefined symbol error).
Ran steamcmd +app_update 730 validate directly beforehand to rule out stale/corrupt server files.

Tested three independently-obtained/built binaries, not just one:

1. Official v1.5.1 release
2. Same-day GitHub Actions CI artifact
3. My own fresh build from current main, using your CI's exact recipe (steamrt/sniper/sdk container, current hl2sdk-cs2 cs2 branch, current metamod-source master)

1 and 2 are byte-identical (matching md5sum) and both fail with undefined symbol: g_bUpdateStringTokenDatabase on load.

3 is a genuinely different binary (different md5sum, confirmed) — it gets past that symbol error, but crashes with an early segfault instead, before the server finishes Steam init. I double-checked this wasn't a permissions artifact on my end (confirmed the .so's executable bit was correctly set before/after testing) — the crash is real either way.

So across three separately-built binaries I get three outcomes, none of them "working": two identical clean-rejection failures, and one that trades that for a harder crash. Given that spread, I don't think this is isolated to something wrong in my install specifically — though I'm glad to compare any config detail (my multiaddonmanager.cfg, Metamod build, anything) if it'd help narrow down what's different from servers where it's working.