| Summary: | dev-lang/php fails to build after profile switch on x86 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Frank Limpert <frank_limpert> |
| Component: | Hardened | Assignee: | The Gentoo Linux Hardened Team <hardened> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bertrand, frank_limpert, me, mjo, php-bugs, ulrich.uhlig, zany |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://github.com/php/php-src/issues/14467 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 911581 | ||
| Attachments: | build.log, emerge --info, emerge -pqv & environment | ||
dev-lang/php-8.1.26-r1 produces the same linker error. I just encountered the same problem with dev-lang/php-8.1.29 on default/linux/x86/23.0/i686/split-usr/hardened Currently installed dev-lang/php-8.1.26-r1 shows the same error on recompile. Other versions like dev-lang/php-8.2.20 fail also. Compiling without opcache USE flag works well. It compiled fine with sys-devel/gcc-13.2.1_p20240113-r1 but seems to break with sys-devel/gcc-13.2.1_p20240210 The error is ld: ext/opcache/jit/.libs/zend_jit.o: warning: relocation against `_tsrm_ls_cache' in read-only section `.text' ld: read-only segment has dynamic relocations My preference would be to mask USE=opcache on x86 as I don't really want to try figure out where the relocation in a JIT is coming from. mjo? (In reply to Sam James from comment #3) > My preference would be to mask USE=opcache on x86 as I don't really want to > try figure out where the relocation in a JIT is coming from. > > mjo? As Christian said: that would not help with the current gcc-13.2.1_p20240210. I got the same error as he got. Sorry for the ambiguous wording, for me all tested versions compile with USE="-opcache" but do not when opcache is selected. This seems to have started with sys-devel/gcc-13.2.1_p20240210. I'm still running dev-lang/php-8.1.26-r1 with opcache enabled and compiled by sys-devel/gcc-13.2.1_p20240113-r1. One quirk though, I had to compile with C(XX)FLAGS -ggdb as otherwise it will reproducibly crash on e.g. loading Roundcube. (Something of a "Heisenfix" when trying to locate the crash.) This looks like https://github.com/php/php-src/issues/14467 We can mask it in the meantime. Hopefully a fix doesn't take too long, and considering that it's broken already, it's not like anyone will be losing access to opcache. On second thought, it might be better to mask only the JIT on x86, if it were possible to do that. I'm going to add an "opcache-jit" flag to the newly-released php-8.3.9 and if that helps, we'll mask only the JIT. I can confirm that on x86 masking JIT with --disable-opcache-jit works for at least dev-lang/php-8.1.29, dev-lang/php-8.2.20, dev-lang/php-8.3.8 which otherwise do not compile. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1050b40799c612f0cf729e9f96c6e91c193c7ad8 commit 1050b40799c612f0cf729e9f96c6e91c193c7ad8 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2024-07-09 20:06:45 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2024-07-10 14:07:09 +0000 profiles/arch/x86: mask dev-lang/php[opcache-jit] Avoids a build failure on hardened profiles, and shouldn't hurt too much elsewhere. Closes: https://bugs.gentoo.org/930145 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> profiles/arch/x86/package.use.mask | 5 +++++ 1 file changed, 5 insertions(+) Should be fixed in the latest 8.3.9? Let me know if not. Or if anyone experiencing this problem is in desperate need of a backport to 8.2.x FWIW, once past the opcache w/ --disable-opcache-jit, 8.2.20 still fails to build with +threads (same type of "read-only segment has dynamic relocations" error.) So you may want to mask threads as well on hardened x86, although this has a cascading effect (no threads in PHP means no threads in Apache, which limits it to mpm_prefork and no http2.) Using +threads is not a problem for me with any version, e.g. just successfully tested dev-lang/php-8.2.20 with "bcmath berkdb bzip2 cli ctype curl fileinfo filter flatfile fpm gd gdbm iconv imap intl ipv6 mhash mysql mysqli nls opcache pdo phar posix readline session simplexml soap sockets sodium sqlite ssl sysvipc threads tidy tokenizer truetype unicode xml xmlreader xmlwriter xslt zip zlib". Not sure what to say. I also have +apache and I had to switch off threads throughout to get a successful build. I don't have any more time to troubleshoot now, but I might come back to this later. (In reply to Stejarel Veres from comment #11) > FWIW, once past the opcache w/ --disable-opcache-jit, 8.2.20 still fails to > build with +threads (same type of "read-only segment has dynamic > relocations" error.) > > So you may want to mask threads as well on hardened x86, although this has a > cascading effect (no threads in PHP means no threads in Apache, which limits > it to mpm_prefork and no http2.) I used to do it too (so no judgment), but FWIW there has always been a big red warning against this: https://www.php.net/manual/en/install.unix.apache2.php USE=threads has historically been a headache but upstream at least runs the test suite with it enabled now so it has gotten a lot better. Thank you for this article, I had not seen it before. I have nothing against the prefork MPM, but using it means no HTTP/2 support (in practical terms.) On Gentoo, +http2 actually requires +threads, so either the event or worker MPM. I find it odd that such a combo (hardened + Apache + threads + PHP + HTTP/2) would not be fully supported in this day and age. ... having said that, I know this is an upstream recommendation, and, as far as Gentoo is concerned, this actually works on x64. I have an age-old system which used to run on bare-metal x86 and is now a VM on x64 hardware (such is the plight with rolling distros.) I am working to migrate it to a new x64 VM, but it takes time. However, from the article you posted, even on x64 they recommend avoiding this combo, unless in a FastCGI setup. I had not considered that option, so I have something to look into now. :) I think that combo doesn't get much attention because PHP's fpm is now used by most people instead. FPM has the advantage of being independent of the web server, so it can be used with with nginx or on Windows with only minor changes. For PHP upstream that means they don't have to care about the internals of every web server like they do with mod_php. FPM also allows you to run each website as a separate user/group, which is a pretty basic security precaution but difficult to do with mod_php. We have www-apache/mpm_itk on Gentoo, but for most people, FPM would be the easier choice. *** Bug 935836 has been marked as a duplicate of this bug. *** Michael, I did see opcache-jit in 8.3.9 but it (accidentally?) got dropped in 8.3.10. It seems to have never landed in 8.2.20+ or 8.1.29+? Disabling opcache-jit is still a needed fix to successfully compile php with opcache on x86. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0da2d7d32a2cfe7375f07de114558ad8bc33c7b8 commit 0da2d7d32a2cfe7375f07de114558ad8bc33c7b8 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2024-10-25 17:15:41 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2024-10-25 17:15:52 +0000 dev-lang/php: add 8.2.25 Upstream bugfix release, and add opcache-jit workaround to the 8.2.x series. Bug: https://bugs.gentoo.org/930145 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> dev-lang/php/Manifest | 1 + dev-lang/php/php-8.2.25.ebuild | 890 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 891 insertions(+) The opcache-jit flag should still be there in the 8.3 series (I just added 8.3.13 a second ago and double-checked). The flag is automatically disabled on x86 machines though, which should have the desired effect: it just builds. I originally did not backport the fix to 8.2, but I have now. IIRC 8.1 is missing the separate ./configure flag. |
Created attachment 890970 [details] build.log, emerge --info, emerge -pqv & environment After switching from profile default/linux/x86/17.0/hardened to default/linux/x86/23.0/i686/split-usr/hardened emerge -e @world failed to re-build dev-lang/php-8.2.15 with a linker error: "read-only segment has dynamic relocations". Please see the attached logs. I have already tried to downgrade to dev-lang/php-8.1.25, but the linker error remained the same.