glibc-2.41 release notes: dlopen and dlmopen no longer make the stack executable if a shared library requires it, either implicitly because of a missing GNU_STACK ELF header (and default ABI permission having the executable bit set) or explicitly because of the executable bit in GNU_STACK, and the stack is not already executable. Instead, loading such objects will fail. Apparently this affects discord-0.0.84 https://archlinux.org/news/glibc-241-corrupting-discord-installation/
The Arch article says it was fixed in package version 0.0.84-1, and in the changelog for that version, the only change was updating the script to point to the new upstream package, so I think the issue was fixed upstream and since we already and only ship the 0.0.84 upstream package, there should be no problem. It would help if someone using glibc-2.41 could verify the issue on 0.0.83 and confirm it's fixed on 0.0.84 though.
I've just tested 0.0.83 and 0.0.84, and it is indeed fixed with 0.0.84. The issue was two node modules in the config directory of Discord were built with execstack when they shouldn't have been. Not sure how that would've been solved on Gentoo's side, since the modules sit in the user's home directory.
OK. Feel free to close this then. I just wanted to make sure that people know...
Thank you Kostadin!
