Summary: | games-util/libstrangle: broken at runtime with glibc-2.36 due to hash-style changes (fatal error: cannot find real dlsym) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ionen Wolkens <ionen> |
Component: | Current packages | Assignee: | Ionen Wolkens <ionen> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | pacho |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://gitlab.com/torkel104/libstrangle/-/issues/59 | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=864100 https://sourceware.org/bugzilla/show_bug.cgi?id=29456 https://bugs.gentoo.org/show_bug.cgi?id=347761 https://bugs.gentoo.org/show_bug.cgi?id=527504 |
||
Whiteboard: | functioning workaround, no stable blocker | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 863215 |
Description
Ionen Wolkens
![]() > An alternate option could be to restore --hash-style=both on glibc until (at
> least) steam updates their methods which would give time here too, but feel
> using glibc defaults would be better on the long term.
Albeit there may be a chance it will remain the default, guess have to wait to see what glibc upstream will do about this wrt see also.
Feels like a hack (to replace a hack anyway...), but there is another way[1] could potentially use if glibc 2.36 is keyworded without DT_HASH. But I'll wait to see where this goes given there's still the steam issues either way. [1] https://gitlab.com/hkva1/libstrangle-dlsym-fix The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=482fa96f4ed12c6c5fdb8c6aea17340136ecbdac commit 482fa96f4ed12c6c5fdb8c6aea17340136ecbdac Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2022-09-20 20:18:51 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2022-09-20 20:20:17 +0000 sys-libs/glibc: Introduce useflag hash-sysv-compat, untested so far Bug: https://bugs.gentoo.org/864100 Bug: https://bugs.gentoo.org/863863 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-libs/glibc/glibc-2.36-r3.ebuild | 1615 +++++++++++++++++++++++++++++++++++ sys-libs/glibc/glibc-9999.ebuild | 8 +- sys-libs/glibc/metadata.xml | 1 + 3 files changed, 1623 insertions(+), 1 deletion(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c35eda158de43d8d35c342eabb388a1505e5be4c commit c35eda158de43d8d35c342eabb388a1505e5be4c Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-09-20 23:06:56 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-09-20 23:12:59 +0000 games-util/libstrangle: rdepend on glibc[hash-sysv-compat] Not closing bug #863863 yet given this isn't due to be a permanent solution. If steam/wine issues are resolved and this is the only package needing this, will look at other workarounds if upstream hasn't done anything yet. Bug: https://bugs.gentoo.org/863863 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> ....1_p20220222.ebuild => libstrangle-0.1.1_p20220222-r1.ebuild} | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) FYI: following commit to a different package (https://github.com/mumble-voip/mumble/commit/6f19d7ebfd7565843b3c56484af624afb5956c0f) gives enough info to produce a proper fix that *does* read DT_GNU_HASH. Besides that block describing how it's supposed to be parsed, you only need to adjust the logic in src/opengl/real_dlsym.c a little so that libstrangle can accept either DT_GNU_HASH or DT_HASH. (only thing I'm unsure of is if I done it the right way for both 32 *and* 64 bit - one of them definitely *was* working) (In reply to Rafał Mużyło from comment #5) > FYI: following commit to a different package > (https://github.com/mumble-voip/mumble/commit/ > 6f19d7ebfd7565843b3c56484af624afb5956c0f) gives enough info to produce a > proper fix that *does* read DT_GNU_HASH. > > Besides that block describing how it's supposed to be parsed, you only need > to adjust the logic in src/opengl/real_dlsym.c a little so that libstrangle > can accept either DT_GNU_HASH or DT_HASH. > > (only thing I'm unsure of is if I done it the right way for both 32 *and* 64 > bit - one of them definitely *was* working) Oh it's totally doable, but it's not easy for someone with no familiarity with the codebase. I suggest sharing this upstream. Yeah, been mostly waiting for an accepted solution upstream but they haven't been very active till the last quickfix to start using DT_HASH. If someone sends a PR upstream that seems to work, I'm open to adding it here regardless of merge status. May later consider just last-riting this given upstream seems to have went entirely inactive. I haven't really needed this in a while too. Not that there's any rush to while USE=hash-sysv-compat continues to exist, so unless someone reports it's broken further I'll leave it alone. |