Announcement

Collapse
No announcement yet.

Glibc 2.36 Dropping DT_HASH Has Been Breaking Easy Anti Cheat Games With Steam Play

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Glibc 2.36 Dropping DT_HASH Has Been Breaking Easy Anti Cheat Games With Steam Play

    Phoronix: Glibc 2.36 Dropping DT_HASH Has Been Breaking Easy Anti Cheat Games With Steam Play

    Those on rolling-release Linux distributions that are quick to adapt to new toolchain updates are finding Easy Anti Cheat (EAC) enabled games breaking when running on the recently released Glibc 2.36. The breakage stems from the DT_HASH section being dropped in GNU C Library but EAC being among the few software still expecting that section rather than DT_GNU_HASH...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Glibc devs stand on this is quite clear:

    - DT_GNU_HASH was added in 2006, and for the last 16 years has been the modern standard on Linux. The glibc change was made to allow the distributions to choose how ackwards compatible they want to be with ELF consumers and the hash function and section. This is not ABI, just like the PLT and RELRO are not ABI.
    - One specific use case of "Easy Anti-Cheat" software is impacted by this implementation detail change which impacts ELF consumers that require DT_HASH.
    - The choice to have DT_HASH is with the distributions. If this breaks specific applications then those developers need to engage with the ecosystem or adapt their software.

    Comment


    • #3
      Originally posted by ms178 View Post
      Glibc devs stand on this is quite clear:

      - DT_GNU_HASH was added in 2006, and for the last 16 years has been the modern standard on Linux. The glibc change was made to allow the distributions to choose how ackwards compatible they want to be with ELF consumers and the hash function and section. This is not ABI, just like the PLT and RELRO are not ABI.
      - One specific use case of "Easy Anti-Cheat" software is impacted by this implementation detail change which impacts ELF consumers that require DT_HASH.
      - The choice to have DT_HASH is with the distributions. If this breaks specific applications then those developers need to engage with the ecosystem or adapt their software.
      This is why it's entirely valid to be specific which distributions and versions of those distributions are supported by said software, and telling people using other distributions they won't be supported if something breaks. This is one of those cases the reason why is glaringly obvious, among others.

      That said, the problem is downstream, not the GlibC project as you say.

      Comment


      • #4
        16 years ago?
        copy DT_GNU_HASH to DT_HASH
        leave both , hell add DT_SYSTEMD_HASH

        Comment


        • #5
          My question is: What if some old and barely maintained software uses DT_HASH? Will they just break with future Glibc releases?

          It's sad that GlibC devs are so myopic about backwards compatibility -- 12 years is nothing. The community needs to think about this seriously and simply don't break apps for no good reason.

          Linus talked about this 8 years ago and almost nothing changed, unfortunately. He even says that Valve can be the salvation of the Linux desktop because noone will distribute multiple binaries for GNU/Linux.
           
          Last edited by evasb; 14 August 2022, 12:08 AM.

          Comment


          • #6
            why =both mean drop?

            Comment


            • #7
              Good. "Anti-cheat" software is basically malware anyway.

              Comment


              • #8
                MakeMKV also had this problem a few years back, but I got upstream to fix it. It impacted Gentoo, which only used DT_GNU_HASH until a short time before glibc made this change. Gentoo switched back to both precisely because of this issue without realising that glibc was about to go the other way.

                Comment


                • #9
                  Shouldn't they bump the major version number if they want to remove APIs from the library? glibc 3.0

                  At least then Steam would still pick up 2.x.x library that is installed. Version numbers are there for a reason...

                  Comment


                  • #10
                    Originally posted by OneTimeShot View Post
                    Shouldn't they bump the major version number if they want to remove APIs from the library? glibc 3.0
                    Yeah. GNU people apparently no longer know what semantic version numbers are.

                    I guess it's now yet another compatibility fix Valve has to carry in their Linux runtimes.

                    Comment

                    Working...
                    X