As per upstream bug noted in URL field above: $ cat add.php <?php $l = 2 + 2; echo "l=$l\n"; ?> $ /var/tmp/portage/dev-lang/php-5.4.40/work/sapis-build/cli/sapi/cli/php add.php Segmentation fault x32 compilation succeeds (although the resulting PHP binary is likely no good) with USE="-phar". dev-lang/php-5.5.24 appears to be fixed, and executes the above code correctly.
zend_operators need to be patched or you'll eventually hit integer overflows. This is what I've been using since 5.6.13: https://github.com/tmarques/overlay_x32-abi/blob/master/dev-lang/php/files/zend_operators-x32.patch For that version it worked fine but the most recent one fails more tests, though it doesn't seem related. I've asked this to be merged upstream but since PHP 7 was supposed to support x32 better, it has been neglected.
*** Bug 570792 has been marked as a duplicate of this bug. ***
Upstream changes are needed to fix this in all PHP versions. I see that Tiago is still working on it: https://bugs.php.net/bug.php?id=69693
Hey. Upstream seems not to care much. Any consideration for applying local patches? These mostly work for PHP 5 but there's new issues with PHP 7 that I haven't been able to solve yet.
(In reply to Tiago Marques from comment #4) > Hey. > > Upstream seems not to care much. Any consideration for applying local > patches? These mostly work for PHP 5 but there's new issues with PHP 7 that > I haven't been able to solve yet. How likely is it that the patches will get outdated? I'm not able to test it, but if there's a way to apply the x32 patches only when the user is actually using x32, I guess it couldn't hurt. On the other hand, I wouldn't hold up a new version of PHP for everyone just because the patchset fails to apply cleanly over the new version. That would likely leave x32 users with a crashing build instead of a buggy binary. It would be better for everyone if these could go upstream, but I understand how hard it can be to find someone to review and merge them.
(In reply to Michael Orlitzky from comment #5) > (In reply to Tiago Marques from comment #4) > > Hey. > > > > Upstream seems not to care much. Any consideration for applying local > > patches? These mostly work for PHP 5 but there's new issues with PHP 7 that > > I haven't been able to solve yet. > > How likely is it that the patches will get outdated? > > I'm not able to test it, but if there's a way to apply the x32 patches only > when the user is actually using x32, I guess it couldn't hurt. On the other > hand, I wouldn't hold up a new version of PHP for everyone just because the > patchset fails to apply cleanly over the new version. That would likely > leave x32 users with a crashing build instead of a buggy binary. > > It would be better for everyone if these could go upstream, but I understand > how hard it can be to find someone to review and merge them. I agree. As it is, since there is no x32 specific ebuild masking, this causes random failures when integers overflow. These patches run x86 assembly vs x86-64, which fixes overflows. I have not coded improved x32 mode assembly and PHP probably needs further patching to use the extra registers. Automated testing shows mostly improvements vs x86 assembly. This is due to x32's 64bit time values, which causes automated testing that was expecting overflows to now fail (as it doesn't overflow anymore). I have been also running the code in a production environment with no ill effects to point out. The patches are not likely to be outdated, as they alter a part of the code that is rarely - if ever - changed. I have mostly been updating my local ebuilds when a new version comes out. I'll be updating this to the latest PHP 5 this week and post an ebuild.
I don't suppose this commit fixed your problem? https://github.com/php/php-src/pull/3665 In any case, I think we have to give up on this bug. The x32 sub-profile is nearly dead in Gentoo, with the only changes in the past few years being to mask the growing list of packages that don't work with it. Considering that you may be the only users of both x32 and PHP (if you are still using them) the risks of custom-patching everyone's PHP outweigh the benefits.
I mostly agree with your comments. I had to stop working on this for a (good) while. Moved to PHP 7.x and couldn't find a way to patch it. Though the suggested patch looks the same approach, though it isn't correct. x32 code is x64 code (calling conventions) and not x86-32, which is what that patch does. Such patch is also lacking without updated tests, as some will fail on x32 despite having the right output. Right now I would mark this as "needinfo" while I have a look at it, if you may. --- In an ideal world, x32 profile would exist and specific apps like games or workstation software would only work and compile as 64bit apps - it is a waste to have browser tabs or other software using more resources for no good reason, while being slower due to cache trashing. On Windows I've recently tested a Core 2nd gen chip that was 10-15% faster on Firefox x86-32 vs x86-64, which would be slower than x32. There are more CPUs like that. The problem in Gentoo right now is that apps that support ABI_X86 have an immutable x32 - "64 (x32)" - value that also builds x86-64 versions by default. This means one can't disable broken apps and use 64bit versions. Going forward this would be a problem for software that would require addressing more than 4GiB. I got stuck on building 'rust' and will keep having a look at this and PHP when I can.
(In reply to Tiago Marques from comment #8) > The problem in Gentoo right now is that apps that support ABI_X86 have an > immutable x32 - "64 (x32)" - value that also builds x86-64 versions by > default. This means one can't disable broken apps and use 64bit versions. > Going forward this would be a problem for software that would require > addressing more than 4GiB. > > I got stuck on building 'rust' and will keep having a look at this and PHP > when I can. FWIW, you can unforce that 64 in profiles if you want to.
> FWIW, you can unforce that 64 in profiles if you want to. I know, tks. I meant the x32 is immutable, so you can't build browsers or other software in 64bit while running desktop and system software in x32. On 64bit one has an innaccessible x32 flag: ABI_X86="(64) -32 (-x32)" I managed to get 64 bit binary packages working, not from Portage, but it was hard to track the dependencies for that and get them built.
To clarify, if you're on x32 and some package (like rust) is broken, you can't just build the x86-64/amd64 ABI version and ignore the x32 ABI one.
(In reply to Tiago Marques from comment #8) > > Right now I would mark this as "needinfo" while I have a look at it, if you > may. > Finally getting around to this.
