undefined | Better HN

0 pointsakdev1l1d ago0 comments

Sorry I am not sure if 2.12 is a a recent release or older, I made up this number up

If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work

>If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux.

Not really a show stopper, vendors just do what vendors do and bundle all their dependencies in. Similar to windows when you use anything outside of the win32 API.

The only problem with this approach is that glibc cannot have multiple versions running at once. We have “fixed” this with process namespaces and hence containers/flatpak where you can bundle everything including your own glibc.

Naturally the downside is that each app bundles their own libraries.

0 comments

em-bee1d ago

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

akdev1lOP1d ago

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_dos11d ago

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

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

em-bee1d ago

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.

1 more reply

j / k navigate · click thread line to collapse

0 pointsakdev1l1d ago0 comments

Sorry I am not sure if 2.12 is a a recent release or older, I made up this number up

If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work

>If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux.

Not really a show stopper, vendors just do what vendors do and bundle all their dependencies in. Similar to windows when you use anything outside of the win32 API.

Naturally the downside is that each app bundles their own libraries.

0 comments

em-bee1d ago

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

akdev1lOP1d ago

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_dos11d ago

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

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

em-bee1d ago

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.

1 more reply

j / k navigate · click thread line to collapse