The only problem with this approach is that glibc cannot have multiple versions running at once

that's not correct. libraries have versions for a reason. the only thing preventing the installation of multiple glibc versions is the package manager or the package versioning.

this makes building against an older version of glibc non-trivial, because there isn't a ready made package that you can just install. the workarounds take effort:

https://stackoverflow.com/questions/2856438/how-can-i-link-t...

the problem for companies developing on linux is that it is not trivial

▲

akdev1l 3 hours ago | parent | next [-]

glibc must match the linker so you would need a separate linker and the binaries usually have a hardcoded path to the system linker (and you need to binary patch the stuff - https://stackoverflow.com/questions/847179/multiple-glibc-li...)

So in practice you can only have 1 linker, 1 glibc (unless you do chroot or containers and at that point just build your stuff in Ubuntu 12.04 or whatever environment)

▲

seba_dos1 4 hours ago | parent | prev [-]

You compile in a container/chroot with the userspace you target. Done.

In the context of games, that will likely be Steam Runtime.

▲

em-bee 3 hours ago | parent [-]

it's not that simple. you want to be able to use a modern toolchain (compilers that support the latest standards) but build a binary that runs on older systems.

the only way to achieve that is to get the older libraries installed on a newer system, or you could try backporting the new toolchain to the older system. but that's a lot harder.

	▲	seba_dos1 2 hours ago \| parent [-]
		It may be hard-ish, sometimes. Sometimes it's a breeze. And sometimes you can just use host's toolchain with container's sysroot and proceed as if you were cross-compiling. Most of the time it's not a big deal.