Filing for tracking, due to [1] e.g. with glibc-2.36 (or without --hash-style=both on older glibc): $ strangle 60 glxgears Strangle: fatal error: cannot find real dlsym: (null) Aborted (still usable with vulkan as it uses vulkan layers) Fixing needs some understanding of finding the real dlsym with DT_GNU_HASH rather than DT_HASH (or some other, better way if it exists), see src/opengl/real_dlsym.c. Fail that, may be possible to temporarily rip out dlsym support which would gimp libstrangle but still be usable with most things (but haven't really looked at this yet, will give some time to upstream). Related to this, steam is also affected[2] 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. [1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e47de5cb2d4dbecb58f569ed241e8e95c568f03c [2] https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1206888814
> 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.
