Cannot link to Epic Online Services (EOS SDK) within the runtime environment

[SheridanR]

Hi,

My game uses the Epic Online Services SDK to support online crossplay between the PC/Steam version of the game, the PC/Epic version, and the Nintendo Switch version. But if I attempt to link to the EOS SDK using the scout runtime (specifically the toolbox container) I get a couple of linker errors:

~/dependencies_linux/eos-sdk/SDK/Bin/libEOSSDK-Linux-Shipping.so: undefined reference to `secure_getenv@GLIBC_2.17'
~/dependencies_linux/eos-sdk/SDK/Bin/libEOSSDK-Linux-Shipping.so: undefined reference to `getauxval@GLIBC_2.16'

Looks like EOS was built using glibc v2.16 / v2.17, so it's understandable this doesn't link if the current steam runtime doesn't have this, but I don't have access to the source for EOS SDK so I can't rebuild the library myself in the runtime environment to resolve the issue. So what should I do? Try older versions of EOS SDK until I find one that works?

Epic provides a fairly major service for us, and though I realize that's not Valve's responsibility, surely we're not the only developer trying to use EOS for our game on Steam. Is there any chance for greater support for EOS in the steam runtime in the future?

[SheridanR]

Update: attempting to build using Epic's oldest publicly available version yielded the same result, so that is a no-go.

[smcv]

In general, the only thing Steam on Linux guarantees is that all libraries are at least as new as the ones in scout (approximately Ubuntu 12.04), which is very old and includes glibc 2.15. If the EOS SDK ships precompiled binaries that require a newer glibc, then unfortunately the EOS SDK is not fully compatible with scout.

The scout runtime cannot really provide a newer glibc than the one it already has: it's constrained by backwards compatibility requirements. We can't ship a backport of glibc with Steam for various annoying technical reasons, and putting a newer glibc in the SDK would result in everything compiled in the SDK getting a dependency on that newer glibc, whether it genuinely needs it or not.

One option for addressing this would be to ask Epic to provide a version of the EOS SDK that was compiled in the Steam Runtime 1 'scout' environment, which would make it maximally backwards-compatible.

Another way to address this might be to switch your game's runtime environment from Steam Runtime 1 'scout' to Steam Runtime 3 'sniper', by compiling it in https://gitlab.steamos.cloud/steamrt/sniper/sdk and configuring Steam to run it in the sniper environment. The intention is that at some point this will become available as a "self-service" feature via the Steamworks partner web interface, which can be used by any game that benefits from a newer library stack. However, this mechanism is not yet ready, so configuring a game to run in sniper currently requires manual setup by a Valve developer. @TTimo might be able to help you with that, or if you already have a Valve contact you could ask them? A few games are already using this, mostly open-source projects for now: Battle for Wesnoth, Endless Sky, Retroarch.

Another option would be to document your game as requiring a newer OS (whatever is the oldest you've tested on), and dlopen() the EOS SDK instead of using a hard dependency at link time. At runtime, if the host OS's glibc version is new enough it should load successfully, even though it would not have loaded successfully in the scout SDK.

[SheridanR]

The scout runtime cannot really provide a newer glibc than the one it already has: it's constrained by backwards compatibility requirements.

Tell me about it, this is why we used to use Ubuntu 18.04 LTS for our previous build system. But we found issues at runtime when we ran our Ubuntu-compiled binaries under SteamOS, so now we are pivoting to the Steam Runtime SDK for hopefully better results. I totally get that this is a balancing act between supporting older OSs with older versions of glibc, versus using new glibc and making it easier for developers.

I'll reach out to Epic and ask them to build a version for the Steam runtime. If they do not, skipping the hard link in favor of dlopen() sounds like a reasonable solution, because as you say it ought to work provided the user's OS is newer than 10 years old (glibc 2.17 was published in 2012)...