Fedora 38 LLVM vs. Team Fortress 2

Unfortunately this is exactly the type of stuff that makes supporting commercial apps on linux a nightmare. Weird crashes due to weird linking of system libraries.<p>Common distros are very adamant about dynamic linking everything in order to support the use case of &quot;core library has vulnerability, upgrade it in place without rebuilding consuming apps.&quot; Along with a desire to avoid &quot;dll hell&quot; and force a single canonical version of every library systemwide. This leads to these sorts of issues.<p>Windows gets around it by letting applications put the DLLs they care about beside the executable, and having it check there first by default.

This is a predictable outcome of overriding the global operator new. It remains annoying that this was ever allowed, and is a constant source of pain for c++ standard library implementations.

I loved the premise of the article, though I really wish the author had gone into detail about how he discovered the root cause.

Funnily enough, on Half-Life 1 engine-based games (i.e. the engine that came before HL2 - on which Team Fortress 2 runs; such as Counter-Strike 1.6), a different allocator problem exists -- glibc&#x27;s malloc() just decides to fail miserably[0] on some setups.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;ValveSoftware&#x2F;halflife&#x2F;issues&#x2F;3158">https:&#x2F;&#x2F;github.com&#x2F;ValveSoftware&#x2F;halflife&#x2F;issues&#x2F;3158</a>

It should be straightforward to make a little LD_PRELOAD shim to implement the new operator new on top of old overloads and thus restore proper functioning.<p>It would be a gross kludge, though.

Whole graphics drivers using LLVM in the backend has caused countless issues. The way I look at it one of the main problems is that graphic API libraries shouldn&#x27;t leak symbols from implementation details like them using LLVM. They should expose only the graphics API and nothing more.

Isn&#x27;t this the reason why people recommend using the flatpak version of Steam ?

Fedora 38 includes the LLVM15 libs to maintain backwards compatibility.<p>Why is this automatically using a new, incompatible solib, instead of a versioned solib?

related: this talk that I made 2 years ago about an experiment to ship static executables on linux that could do graphics: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=pq1XqP4-qOo">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=pq1XqP4-qOo</a>

Valve does this for a couple of their games, see a similar issue with Dota 2[0].<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;ValveSoftware&#x2F;Dota-2&#x2F;issues&#x2F;2285">https:&#x2F;&#x2F;github.com&#x2F;ValveSoftware&#x2F;Dota-2&#x2F;issues&#x2F;2285</a>

I thought TF2 was pretty much 100% hacked... like no legit non-hackers playing except at LAN parties.

It&#x27;s unfortunate but the Steam experience on Linux seems to be progressively getting worse (outside of Steam Deck ofc). The Steam client is often borderline unusable for Linux users. You can find many issue threads on GitHub reporting client freezes and crashes.<p>It seems like a big part of the issues is a lack of maintenance. TF2 would actually run better on Linux via Proton but VAC isn&#x27;t enabled so you can&#x27;t join the vast majority of servers.<p>Valve also has existing Source engine tooling that allows Linux ports to drop OpenGL entirely (dxvk-native as used by Portal 2 and L4D2) but they haven&#x27;t added it to TF2... :(