Other distros like Ubuntu override GCC's default stack alignment to 4-bytes. This means that some binaries compiled for those other distros are liable to segfault on Gentoo boxes due to stack alignment issues. I encountered this problem playing games from Steam, but it may also occur with other foreign binaries (and anecdotally with Windows binaries on wine). This can be worked around by building certain programs like wine, libxcb, and glibc with the -mstackrealign cflag. However, the glibc ebuilds use flag-o-matic's strip functions, and one of them is removing -mstackrealign. I've used a modified glibc ebuild to append the flag, and I'm able to play Borderlands 2 now, but a more permanent solution would be for the eclass to allow future -mstackrealign builds without my treachery. Notice that I'm not filing against glibc itself, because this flag-append hack does not completely solve the problem, nor is it applicable to all users/systems. The proper fix would be for the eclass to allow the *option* of building with -mstackrealign across the board, at the user's discretion.
(In reply to Michael Huss from comment #0) > Other distros like Ubuntu override GCC's default stack alignment to 4-bytes. > This means that some binaries compiled for those other distros are liable to > segfault on Gentoo boxes due to stack alignment issues. I'm pretty sure distros do not do that. It's an x86 ABI violation. There used to be a time when gcc did not do 16-byte stack alignment. Now it always does. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496#c9 But ancient binaries still exist. > I encountered this > problem playing games from Steam, but it may also occur with other foreign > binaries (and anecdotally with Windows binaries on wine). I think it's a wine bug not to add explicit realignment for each potential transitions from PE land to ELF land. Usually it's just a matter of sprinkling a few attributes like: https://gitweb.gentoo.org/repo/gentoo.git/tree/games-emulation/zsnes/files/zsnes-1.51-stack-align-v2.patch But I totally understand it's a hard surface to cover. > This can be worked around by building certain programs like wine, libxcb, > and glibc with the -mstackrealign cflag. However, the glibc ebuilds use > flag-o-matic's strip functions, and one of them is removing -mstackrealign. > I've used a modified glibc ebuild to append the flag, and I'm able to play > Borderlands 2 now, but a more permanent solution would be for the eclass to > allow future -mstackrealign builds without my treachery. > Notice that I'm not filing against glibc itself, because this flag-append > hack does not completely solve the problem, nor is it applicable to all > users/systems. The proper fix would be for the eclass to allow the *option* > of building with -mstackrealign across the board, at the user's discretion. We can whitelist -mstackrealign for filter-cflags. It should be a safe option.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2004d466896f9b81452c7bdac1ee00866b8f0ff1 commit 2004d466896f9b81452c7bdac1ee00866b8f0ff1 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-02-13 21:01:27 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-02-13 21:03:30 +0000 flag-o-matic.eclass: whitelist -mstackrealign for 'strip-flags' Allow '-mstackrealign' in ebuilds like glibc to force stack realignment. That will allow running ancient (or foreign) binaries that don't maintain 16-byte stack alignment. See bug #677852 for example. Reported-by: Michael Huss Closes: https://bugs.gentoo.org/677852 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/flag-o-matic.eclass | 7 +++++++ 1 file changed, 7 insertions(+)
