This lets us easily inherit features/wd40 for just 32ul,
as 64ul now has Rust.
profiles/default/linux/sparc/17.0 is now purely for 32-bit (64-bit
kernels still, just like before), rather than being used partly
by the 64-bit (64ul) subprofile.
Bug: https://bugs.gentoo.org/769467
See: ff1eda53e7
See: 0a1c580aff
See: 40a8f13c5c
Signed-off-by: Sam James <sam@gentoo.org>
Older 32-bit x86 binaries aligned the stack to 4 bytes, whereas modern
binaries align to 16 bytes. These older binaries sometimes segfault when
newer libraries use SSE instructions. This is becoming increasingly
common. Applying the -mstackrealign flag to the 32-bit build works
around the issue but at a performance cost. Other popular
distributions always apply this.
[sam: There's no good choices here. As Ionen pointed out (I'd missed
any reports of this), this ends up getting worse with GCC 12's
default-on vectorisation at -O2. Let's make it optional for now for
32-bit/x86 (irrelevant for other arches, it's specific to x86 ABI).
ncurses is going to need similar treatment. If we end up having
to do this for far more packages, we may revisit and e.g.
just append-flags in ebuilds for right ABI and tell users
to set -mno-stackrealign, or similar.
Another option would be to set this globally by default (again,
this is only ever for x86), but it'd possibly be a big performance
hit (and bad enough doing it in glibc, but it's unavoidable).
The only saving grace here is that there aren't _that_ many
libraries with such longevity & ABI stability from back then
that older applications are using.]
Bug: https://bugs.gentoo.org/616402
Bug: https://github.com/taviso/123elf/issues/12
See: 02aa6328a7
Signed-off-by: Sam James <sam@gentoo.org>
Older 32-bit x86 binaries aligned the stack to 4 bytes, whereas modern
binaries align to 16 bytes. These older binaries sometimes segfault when
newer libraries use SSE instructions. This is becoming increasingly
common. Applying the -mstackrealign flag to the 32-bit build works
around the issue but at a performance cost. Other popular
distributions always apply this.
[sam: There's no good choices here. As Ionen pointed out (I'd missed
any reports of this), this ends up getting worse with GCC 12's
default-on vectorisation at -O2. Let's make it optional for now for
32-bit/x86 (irrelevant for other arches, it's specific to x86 ABI).
ncurses is going to need similar treatment. If we end up having
to do this for far more packages, we may revisit and e.g.
just append-flags in ebuilds for right ABI and tell users
to set -mno-stackrealign, or similar.
Another option would be to set this globally by default (again,
this is only ever for x86), but it'd possibly be a big performance
hit (and bad enough doing it in glibc, but it's unavoidable).
The only saving grace here is that there aren't _that_ many
libraries with such longevity & ABI stability from back then
that older applications are using.]
Bug: https://bugs.gentoo.org/616402
Bug: https://github.com/taviso/123elf/issues/12
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
Closes: https://github.com/gentoo/gentoo/pull/25858
Signed-off-by: Sam James <sam@gentoo.org>
The stack alignment issue affecting compatibility with older 32-bit
binaries is specific to amd64 and x86.
The workaround incurs a performance cost on the 32-bit build, so enable
the flag by default on amd64 but not on x86. Other popular distributions
always enable this workaround.
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
Seems to be a dodgy old autoconf bug. No source configure.in/.ac in the
tarball so can't easily fix it either, sadly.
Just force off the test as lutime doesn't ever exist on Linux
but I'm not sure if lutime is even a thing anyway (lutimeS, perhaps?).
Closes: https://bugs.gentoo.org/854213
Signed-off-by: Sam James <sam@gentoo.org>
Sam James
Matthias Maier
James Le Cuirot
David Seifert
Matt Turner
Mike Pagano
Alex Xu (Hello71)
Matthew Thode
Arthur Zamarin
Agostino Sarubbo
Keri Harris
Zac Medico
Thomas Beierlein