I thought TF2 was pretty much 100% hacked... like no legit non-hackers playing except at LAN parties.
Fedora 38 LLVM vs. Team Fortress 2
51–60 of 111 posts
Re: Fedora 38 LLVM vs. Team Fortress 2
#52Fedora 38 includes the LLVM15 libs to maintain backwards compatibility. Why is this automatically using a new, incompatible solib, instead of a versioned solib?
The LLVM dependency is in the HW-specific driver solib which is loaded by the OpenGL library, which has the same soname as before.
Re: Fedora 38 LLVM vs. Team Fortress 2
#53Earlier quoted context omitted.
Can Linux not trivially do the same thing as windows with LD_PRELOAD? If so why is this more of an issue on Linux than Windows? Is it really less a technical challenge and more just a matter of Linux getting less support from upstream developers?
LD_PRELOAD is too global to be useful, it's hard to scope it to one process (and not child processes). macOS is better in the sense that it clears DYLD_* variables when the dynamic linker has done its work and the process starts. (Although that can also be painful when you want to run a shell script and set DYLD_* outside)
You can compile binaries with additional relative library paths in to them that will take priority over /usr/lib64
Re: Fedora 38 LLVM vs. Team Fortress 2
#54Whole 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't leak symbols from implementation details like them using LLVM. They should expose only the graphics API and nothing more.
Re: Fedora 38 LLVM vs. Team Fortress 2
#55Earlier quoted context omitted.
I was thinking/wondering this myself. Not to reinvent the wheel - more toss an idea around, but a 'venv for LD_PRELOAD' sounds like it'd deal with this pretty handily Not... in a way I'd use as a distribution/release maintainer. Probably as an administrator [of my LAN]
Such things already exist. Eg. Appimage or even docker.
and even that has been managed to be split between snap appimage and flatpak :D
(sorry not meant to offend, long time linux day-to-day user here, but it was just ironic for me to point out fragmentation of fragmentation ^^)
Re: Fedora 38 LLVM vs. Team Fortress 2
#56It 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. It would be a gross kludge, though.
LD_PRELOAD would probably run afoul with VAC though?
Steam on Linux already uses LD_PRELOAD under-the-hood to load the overlay. Valve signs the overlay SO files, so they could be making an exception for Valve-signed-preloads in VAC, but it's also possible that VAC does something else to check for suspicious libraries loaded in.
Re: Fedora 38 LLVM vs. Team Fortress 2
#57Unfortunately 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. Common distros are very adamant about dynamic linking everything in order to support the use case of "core library has vulnerability, upgrade it in place without rebuilding consuming apps." Along with a desire to avoid "dll hell" and force a single canonic…
Can Linux not trivially do the same thing as windows with LD_PRELOAD? If so why is this more of an issue on Linux than Windows? Is it really less a technical challenge and more just a matter of Linux getting less support from upstream developers?
This sounds like it's an interaction with the GPU driver though, which could also happen on windows...
Re: Fedora 38 LLVM vs. Team Fortress 2
#58Whole 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't leak symbols from implementation details like them using LLVM. They should expose only the graphics API and nothing more.
Don't ask me about GNU_UNIQUE...
Due to some wonderful C++ features the dynamic linker is forced to unify symbols across shared libraries, even if those symbols have different versions.
This utterly breaks loading multiple libLLVM's except if you build the copy you care about with -no-gnu-unique (or whatever the flag was called)
I have seen wonderful things like the initializers of an already loaded libLLVM being rerun when a new one is loaded.
Re: Fedora 38 LLVM vs. Team Fortress 2
#59It'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. 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't enabled so you can't join th…
I can’t see how native Linux support is getting worse. Linux users are good at bug reporting. Maybe some developers should care more about compatibility. And yes, especially the heterogeneous setups used by some makes support difficult. I’m worried that Valve puts too much resources into Proton (derivate of WINE) instead of tooling for native ports. Yes, Proton is needed to provide initial compatibility. But Proton i…
I think Valve has a financial incentive to keep Proton compatibility in a positive state, as it increases sales of the Steam Deck and encourages players to remain in their ecosystem. Or, I think it's more likely than the majority of AAA game developers having a financial incentive to maintain Linux versions of their products.
Re: Fedora 38 LLVM vs. Team Fortress 2
#60Unfortunately 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. Common distros are very adamant about dynamic linking everything in order to support the use case of "core library has vulnerability, upgrade it in place without rebuilding consuming apps." Along with a desire to avoid "dll hell" and force a single canonic…
Isn't this exactly the use case for which flatpaks are designed? Isn't Redhat/Fedora in the process of adopting them as the primary way to support third party/proprietary graphical apps like Steam? Doesn't the current Steam flatpak avoid this issue?
TLDR; isn't this already addressed?