It's Now Been Six Years Since Valve Began Rolling Out Steam For Linux

[oiaohm]

some steam-packaged library being compiled with some compile-time switch that won't work with a dependency library on the system etc.

libcapsule work should address a lot of this. As this will allow splitting host libraries from steam package libraries.

https://git.collabora.com/cgit/user/vivek/libcapsule.git/tree/README

I have not see issues with the steam runtime with complile-time switch. Straight up version conflict with libraries yes. Where application expects older library and will not tolerate newer. Arch did give you a lot more newer libraries.

[Almindor]

libcapsule work should address a lot of this. As this will allow splitting host libraries from steam package libraries.

https://git.collabora.com/cgit/user/vivek/libcapsule.git/tree/README

I have not see issues with the steam runtime with complile-time switch. Straight up version conflict with libraries yes. Where application expects older library and will not tolerate newer. Arch did give you a lot more newer libraries.

It's been some time since I tried debugging an issue all the way down (since I have windows too) but last two I remember were:

1. dbus crash on interface changes
2. pulseaudio related crash with some incompatibilities

It might be that #2 was not a library issue but similar to the dbus one a sort of message format issue, not sure, it's been some time. But even then you can have a situation where a compile time switch in lib1 which depends on lib2 can cause a crash if lib2 hasn't been compiled in a specific manner as well. It's a mess.

[oiaohm]

It's been some time since I tried debugging an issue all the way down (since I have windows too) but last two I remember were:

1. dbus crash on interface changes
2. pulseaudio related crash with some incompatibilities

It might be that #2 was not a library issue but similar to the dbus one a sort of message format issue, not sure, it's been some time. But even then you can have a situation where a compile time switch in lib1 which depends on lib2 can cause a crash if lib2 hasn't been compiled in a specific manner as well. It's a mess.

Pulseaudio one I saw a few bugs on steam-runtime issue list. Most were too old pulseaudio interface library in the steam runtime it mixed with newer bad things use to happen.

Steam-runtime in recent years is a lot better than it use to be.

I have not seen a bug in the issue list on the steam-runtime that in fact traced to library compiled option.

Really I have not seen any issues reported against the steam runtime that traced to library compiler flags.

[silmeth]

I’ve had a few bugs, mainly in Unity-based games, related to non-English locale. Games do some funny things with parsing floating-point numbers, and when the decimal separator is set to comma, and not a dot, they hang, change some in-game shop prices in absurd ways, or simply crash (such problems were present in, among others, Oxygen Not Included, Pillars of Eternity). Nothing that setting LC_ALL=C would not fix, but it is annoying and one has to know what the problem is and how to fix it. I haven’t seen similar issues reported on Windows. And as these problems do not happen on English-language systems, there is relatively little help about them on the net…

But, besides locale-related problems which suggest that both engine and game devs test only on en_US.UTF-8 systems, I have encountered almost no problems with native Linux games (I had some minor ones with game updates introducing new bugs, but I think those things happen equally often on Windows). So, for me, it basically just works™.

[LinAGKar]

I’ve had a few bugs, mainly in Unity-based games, related to non-English locale. Games do some funny things with parsing floating-point numbers, and when the decimal separator is set to comma, and not a dot, they hang, change some in-game shop prices in absurd ways, or simply crash (such problems were present in, among others, Oxygen Not Included, Pillars of Eternity). Nothing that setting LC_ALL=C would not fix, but it is annoying and one has to know what the problem is and how to fix it. I haven’t seen similar issues reported on Windows. And as these problems do not happen on English-language systems, there is relatively little help about them on the net…

You can thank C# for that. Apparently some moron at Microsoft decided to make float.Parse act differently depending on the locale, and have it throw an exception if the locale is something different than what the devs expected.