Не работают игры с Easy Anti-Cheat в steam при glibc 2.36+ Нашел: https://github.com/ValveSoftware/Proton/issues/6051 где описывается проблема, если glibc 2.36+ Дальше нашел пример как в Арче вышли из ситуации: https://github.com/archlinux/svntogit-packages/blob/packages/glibc/trunk/reenable_DT_HASH.patch И большая статья по этому поводу: https://maskray.me/blog/2022-08-20-glibc-and-dt-gnu-hash
Я думаю, что нам не стоит откатывать https://sourceware.org/cgit/glibc/commit/?id=e47de5cb2d4dbecb58f569ed241e8e95c568f03c, пусть лучше проприетарщики актуализируют свой протухший софт.
(Ответ для Dmitry V. Levin на комментарий #1) > Я думаю, что нам не стоит откатывать > https://sourceware.org/cgit/glibc/commit/ > ?id=e47de5cb2d4dbecb58f569ed241e8e95c568f03c, пусть лучше проприетарщики > актуализируют свой протухший софт. Судя из: https://bugs.archlinux.org/task/79292 A quick test with a glibc 2.38 build with --hash-style=both does work for me, so just adding that to the LDFLAGS for glibc seems to be enough, no patch needed.
(In reply to Mikhail Tergoev from comment #2) > Судя из: https://bugs.archlinux.org/task/79292 > > A quick test with a glibc 2.38 build with --hash-style=both does work for me, > so just adding that to the LDFLAGS for glibc seems to be enough, no patch > needed. Патч или не патч это вопрос реализации. Если бы мы хотели откатить это изменение, то откатить указанный Димой коммит было бы самым лучшим решением. Но мы не хотим и дело тут не в способе решения.
Почти наверняка может вылезти где-то ещё, пусть лучше повисит в открытом виде. Всё-таки совместимость с софтом лучше не ломать.
Если вдруг кому-то очень нужно: # cat /etc/apt/vendors.list.d/team.list simple-key "team-glebfm" { Fingerprint "ABADA2EF01C15A653AC3425B51D2B221D1D1C7E6"; Name "glebfm@altlinux.org"; } # tail -1 /etc/apt/sources.list rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64 hasher
# apt-repo add rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64 hasher Так как нужно еще и i586, добавляю и его: # apt-repo add rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth i586 hasher # apt-repo upgrade Получено: 1 http://ftp.altlinux.org glebfm/glibc-hashstyleboth/x86_64 release [2776B] Получено: 2 http://ftp.altlinux.org glebfm/glibc-hashstyleboth/i586 release [2776B] Получено: 3 http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64 release [4238B] Получено: 4 http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64-i586 release [1680B] Получено: 5 http://ftp.altlinux.org ALTLinux/Sisyphus/noarch release [2859B] Получено 14,3kB за 0s (221kB/s). Получено: 1 http://ftp.altlinux.org glebfm/glibc-hashstyleboth/x86_64/hasher pkglist [28,5kB] Получено: 2 http://ftp.altlinux.org glebfm/glibc-hashstyleboth/x86_64/hasher release [125B] Получено: 3 http://ftp.altlinux.org glebfm/glibc-hashstyleboth/i586/hasher pkglist [28,8kB] Получено: 4 http://ftp.altlinux.org glebfm/glibc-hashstyleboth/i586/hasher release [125B] Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64/classic pkglist Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64/classic release Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64/gostcrypto pkglist Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64/gostcrypto release Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64-i586/classic pkglist Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64-i586/classic release Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/noarch/classic pkglist Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/noarch/classic release Получено 57,5kB за 0s (482kB/s). Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Подсчет обновлений... Завершено Следующие пакеты будут ОБНОВЛЕНЫ: glibc glibc-core glibc-debug glibc-devel glibc-devel-static glibc-doc glibc-gconv-modules glibc-i18ndata glibc-locales glibc-nss glibc-pthread glibc-timezones glibc-utils iconv libnsl1 nscd Следующие пакеты будут УДАЛЕНЫ: тут удаляются i586 пакеты включая i586-steam 16 будет обновлено, 0 новых установлено, 111 пакетов будет удалено и 0 не будет обновлено. Что я делаю не так? # cat /etc/apt/sources.list rpm [team-glebfm] http://ftp.altlinux.org/pub/people glebfm/glibc-hashstyleboth/x86_64 hasher rpm [team-glebfm] http://ftp.altlinux.org/pub/people glebfm/glibc-hashstyleboth/i586 hasher
(In reply to Mikhail Tergoev from comment #6) > # apt-repo add rpm [team-glebfm] > http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64 hasher > > Так как нужно еще и i586, добавляю и его: > # apt-repo add rpm [team-glebfm] > http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth i586 hasher Нет, нужно не i586, а x86_64-i586, т.е. arepo. Я про него совсем забыл. Я добавил arepo, теперь можно использовать: rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64 hasher rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64-i586 hasher
x86_64-i586 - первым делом пробовал, но не работало. Теперь всё ок. Античиты снова работают. Оставлю тут простейшую пошаговую инструкцию: # apt-repo add rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64 hasher # apt-repo add rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64-i586 hasher # apt-repo upgrade
(In reply to Mikhail Tergoev from comment #8) > x86_64-i586 - первым делом пробовал, но не работало. Да, я про него забыл совсем, а не только написать про него. > Оставлю тут простейшую пошаговую инструкцию: Без vendors.list не заработает проверка подписи через [team-glebfm].
> Без vendors.list не заработает проверка подписи через [team-glebfm]. Исправляюсь: # apt-repo add rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64 hasher # apt-repo add rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64-i586 hasher # echo -e 'simple-key "team-glebfm" {\n Fingerprint "ABADA2EF01C15A653AC3425B51D2B221D1D1C7E6";\n Name "glebfm@altlinux.org";\n}' >> /etc/apt/vendors.list.d/team.list # apt-repo upgrade
(Ответ для Mikhail Tergoev на комментарий #0) > Не работают игры с Easy Anti-Cheat в steam при glibc 2.36+ > > Нашел: > https://github.com/ValveSoftware/Proton/issues/6051 > где описывается проблема, если glibc 2.36+ > > Дальше нашел пример как в Арче вышли из ситуации: > https://github.com/archlinux/svntogit-packages/blob/packages/glibc/trunk/ > reenable_DT_HASH.patch ... Конечно, стало известно, что «for EPIC Games EAC, there is already a fix for this in EOS SDK 1.15.2 (August 2022) and the corresponding version of the anti-cheat module». Как я понимаю, это разработчикам всех игр нужно пересобраться с обновлённым SDK. В Fedora рассматривали эту проблему https://bugzilla.redhat.com/show_bug.cgi?id=2129358 и решили не ломать Fedora как игровую платформу: * Пн окт 17 2022 Carlos O'Donell <carlos@redhat.com> - 2.36.9000-10 - Enable ELF DT_HASH for shared objects and the dynamic loader (#2129358) (Ответ для Dmitry V. Levin на комментарий #1) > Я думаю, что нам не стоит откатывать > https://sourceware.org/cgit/glibc/commit/ > ?id=e47de5cb2d4dbecb58f569ed241e8e95c568f03c, пусть лучше проприетарщики > актуализируют свой протухший софт. Ну это же просто такой хитрый оборот, всем понятно, что проприетарщики по определению ничего не будут актуализировать. С другой стороны, разработчики glibc считают возможным незаметно выключать поддержку DT_HASH без всякого анонса. Точнее, они-то поменяли умолчание, оставив выбор для разработчиков дистрибутивов, которые в итоге без анонса отключают DT_HASH для glibc, разрушая совместимость. (Ответ для Gleb F-Malinovskiy на комментарий #3) > (In reply to Mikhail Tergoev from comment #2) > > Судя из: https://bugs.archlinux.org/task/79292 > > > > A quick test with a glibc 2.38 build with --hash-style=both does work for me, > > so just adding that to the LDFLAGS for glibc seems to be enough, no patch > > needed. > > Патч или не патч это вопрос реализации. Если бы мы хотели откатить это > изменение, то откатить указанный Димой коммит было бы самым лучшим решением. > Но мы не хотим и дело тут не в способе решения. А какие-то аргументы есть? А видно только «мы хотели» и «мы не хотим». Чем продолжение поддержки совместимости с DT_HASH ухудшает glibc? Почему вы считаете, что лучше иметь два glibc в репозитории, чем один с поддержкой DT_HASH? Считаете ли вы, что АЛЬТ не должен быть игровой платформой? Считаете ли вы, что случайное появление несовместимостей с проприетарным ПО это хорошо, и не стоит ничего делать для исправления?
(In reply to Vitaly Lipatov from comment #11) > (Ответ для Mikhail Tergoev на комментарий #0) > Конечно, стало известно, что «for EPIC Games EAC, there is already a fix for > this in EOS SDK 1.15.2 (August 2022) and the corresponding version of the > anti-cheat module». > Как я понимаю, это разработчикам всех игр нужно пересобраться с обновлённым > SDK. Это вроде было известно -- говорят, что часть игр с EAC прекрасно работает. > Ну это же просто такой хитрый оборот, всем понятно, что проприетарщики по > определению ничего не будут актуализировать. Да, если будет работать, то не будут актуализировать. > С другой стороны, разработчики glibc считают возможным незаметно выключать > поддержку DT_HASH без всякого анонса. Точнее, они-то поменяли умолчание, > оставив выбор для разработчиков дистрибутивов, которые в итоге без анонса > отключают DT_HASH для glibc, разрушая совместимость. В ALT gnu hash исользуется начиная с того, как в binutils 2.17.50.0.3-alt1 (Fri Aug 18 2006) появилась поддержка этой фичи и в gcc 4.1.1-alt8 (Sun Oct 01 2006) была реализована безусловная передача --hash-style=gnu линкеру. Разработчики дистрибутива приняли решение очень давно. Тот факт, что glibc по своим причинам (которые описаны в комментариях к убранным изменениям) считали нужным поддерживать sysv hash style на это решение никак не влияет.
(Ответ для Gleb F-Malinovskiy на комментарий #12) > (In reply to Vitaly Lipatov from comment #11) > > (Ответ для Mikhail Tergoev на комментарий #0) > > Конечно, стало известно, что «for EPIC Games EAC, there is already a fix for > > this in EOS SDK 1.15.2 (August 2022) and the corresponding version of the > > anti-cheat module». > > Как я понимаю, это разработчикам всех игр нужно пересобраться с обновлённым > > SDK. > Это вроде было известно -- говорят, что часть игр с EAC прекрасно работает. > > > Ну это же просто такой хитрый оборот, всем понятно, что проприетарщики по > > определению ничего не будут актуализировать. > Да, если будет работать, то не будут актуализировать. Боюсь, что они в последнюю очередь будут интересоваться тем, что работает на glibc в ALT. > > С другой стороны, разработчики glibc считают возможным незаметно выключать > > поддержку DT_HASH без всякого анонса. Точнее, они-то поменяли умолчание, > > оставив выбор для разработчиков дистрибутивов, которые в итоге без анонса > > отключают DT_HASH для glibc, разрушая совместимость. > В ALT gnu hash исользуется начиная с того, как в binutils 2.17.50.0.3-alt1 > (Fri Aug 18 2006) появилась поддержка этой фичи и в gcc 4.1.1-alt8 (Sun Oct > 01 2006) была реализована безусловная передача --hash-style=gnu линкеру. > Разработчики дистрибутива приняли решение очень давно. Тот факт, что glibc > по своим причинам (которые описаны в комментариях к убранным изменениям) > считали нужным поддерживать sysv hash style на это решение никак не влияет. Это выглядит так, что все не при делах: - разработчики glibc говорят «мы меняем умолчание, вы можете у себя выбрать что нужно» - сопровождающий пакета glibc говорит «мы давно уже выбрали, и изменение в апстриме нас не касается» Но по факту новая версия пакета ломает определённую функциональность. Вы скажите просто, почему заботливо не предупредили, что в новой сборке пакета будет радикальное изменение? Ну может забыли или не знали? Хотя и вопросы в предыдущем комментарии остались без ответа.
(Ответ для Gleb F-Malinovskiy на комментарий #12) ... > В ALT gnu hash исользуется начиная с того, как в binutils 2.17.50.0.3-alt1 > (Fri Aug 18 2006) появилась поддержка этой фичи и в gcc 4.1.1-alt8 (Sun Oct > 01 2006) была реализована безусловная передача --hash-style=gnu линкеру. > Разработчики дистрибутива приняли решение очень давно. Тот факт, что glibc > по своим причинам (которые описаны в комментариях к убранным изменениям) > считали нужным поддерживать sysv hash style на это решение никак не влияет. Не вижу связи между тем, как собираются бинарники (--hash-style=gnu это отличное решение, так сделали все, понятно, что DT_GNU_HASH лучше) и тем ломается ли совместимость в glibc. О влиянии на решение тоже вопросов не было. Картина-то другая. В Fedora в обход фриза проносили возвращение DT_HASH в glibc, чтобы в релизе запускались игры, а у нас будут вопросы на много лет, почему игра не запускается. А ответа-то нет. Если поддержка DT_HASH возвращается двумя строчками LDFLAGS.so="-Wl,--hash-style=both" LDFLAGS-rtld="-Wl,--hash-style=both" при сборке glibc, это вопрос того, будет ли сохраняться совместимость. Зачем рассказывать про binutils?
(In reply to Vitaly Lipatov from comment #14) > Зачем рассказывать про binutils? Ты написал что-то очень странное про умолчания в glibc связанные с выбором hash style, мне пришлось объяснять. Из твоего следующего ответа я могу сделать вывод, что ты не понял моё объяснение.
(In reply to Vitaly Lipatov from comment #13) > Вы скажите просто, почему заботливо не предупредили, что в новой сборке > пакета будет радикальное изменение? Ну может забыли или не знали? Странный вопрос. Забыли, что в EAC делаются такие странные вещи? :) Нет, конечно не знали.
glibc-6:2.38.0.11.g1aed90c9c8-alt1 -> sisyphus: Fri Sep 01 2023 Gleb F-Malinovskiy <glebfm@altlinux> 6:2.38.0.11.g1aed90c9c8-alt1 - Updated to glibc-2.38-11-g1aed90c9c8. - Enabled ELF DT_HASH for shared objects and the dynamic loader (ALT#47150).
