PHP 8.1 and 8.2 on RHEL9: PHP Startup: ^(text/|application/xhtml\+xml) (offset=0): unrecognised compile-time option bit(s) in Unknown on line 0
skaiblinger opened this issue · comments
Hi there,
when executing php -v on a RHEL 9.0 machine I get the following message:
# php -v
PHP Warning: PHP Startup: ^(text/|application/xhtml\+xml) (offset=0): unrecognised compile-time option bit(s) in Unknown on line 0
PHP 8.1.14 (cli) (built: Jan 4 2023 06:45:14) (NTS gcc x86_64)
Copyright (c) The PHP Group
Zend Engine v4.1.14, Copyright (c) Zend Technologies
I first noticed the problem after upgrading to PHP 8.2.1, but the problem persists even after downgrading again and even after completely reinstalling the OS.
I already tried to track down, if the issue is related to an extension, and php-mbstring seems to be the culprit.
# dnf list --installed | grep php
oniguruma5php.x86_64 6.9.8-1.el9.remi @remi-safe
php-cli.x86_64 8.1.14-1.el9.remi @remi-modular
php-common.x86_64 8.1.14-1.el9.remi @remi-modular
php-mbstring.x86_64 8.1.14-1.el9.remi @remi-modular
Could this issue be related to php/php-src#8685 ?
As far as is can tell the issue was fixed in PHP 8.1.8
Sorry I can't support 9.0, but only 9.1
https://blog.remirepo.net/pages/English-FAQ#deps
Especially the upgrade from pcre2 10.37 to 10.40 explain this issue.
You need to fully update your system.
Cherry picking updates is also not supported
P.S. linked issue, reported/fixed by me was indeed related to this issue, but not the proper cause (PHP built using pcre2 10.40 running with 10.37)
Oh.
As it worked until a few weeks ago (around christmas), I never thought this could be a compatibility issue regarding the OS version.
Since I am dealing with a large corporate network here, I personally have little to no control over the used OS version.
Seams like it's time to ask for a few favors or find another solution. RHEL 9 should at least support PHP 8.1 so i would only miss out on 8.2 for now.
Thanks for the info and quick support
As it worked until a few weeks ago (around Christmas),
IT has worked until
https://twitter.com/RemiRepository/status/1597129452554571776
https://twitter.com/RemiRepository/status/1597234347459096577
Ah yeah that makes sense. We mirror the repositories into the corporate network and let them walk through multiple testing-stages, which delays the availability of newer versions for two weeks.
Thanks again for the clarification
I'm sorry bringing this issue up again, but I could not find this information on your website. So just for future reference: How do you determine the minor version of the build servers?
Is it always "latest" or do you only upgrade when necessary for security reasons / bugfixes regarding the PHP version.
Since there are no repositories for the EL minor versions, for me there would always be the possibility for breaking changes even in PHP hotfix versions. Have you considered a paid service for EL customers to have repositories targeting the minor versions?
Maybe I'm not the only one who wants a more modern PHP than what the AppStreams offer and has no way of using containers.
Anyway: Thanks for all your effort and keep up the good work
How do you determine the minor version of the build servers?
- announced on twitter / discord
- on the FAQ
- on PHP announce page (always used first for a RC version), ex
- on the wizard https://rpms.remirepo.net/wizard/
- remi-release package version, changelog and dependency
$ rpm -q remi-release
remi-release-9.1-2.el9.remi.noarch
$ rpm -q --requires remi-release
(redhat-release >= 9.1 or centos-stream-release >= 9)
epel-release = 9
...
$ rpm -q --changelog remi-release
* Thu Nov 17 2022 Remi Collet <remi@remirepo.net> - 8.7-2 and 9.1-2
- raise dependency on redhat-release >= 8.7 or 9.1
- add 2023 key
...
I'm used to wait a few weeks after a new point release before using it, also waiting for main clones to be ready (AlmaLinux, RockyLinux...)
Ah I see.
You got the information, which version the build servers are at, for every release, and the general strategy is to keep the build servers up to date, with a bit of a delay for the main clones to catch up.
So it's simply my strange use-case which is not compatible with this "fast" changes. I think the EL AppStreams will better suit my requirements, even if these are a bit slower than i would wish for.
Thanks again for the support.
Just for memory and to be exact, this is not related to pcre update but to pcre2 (I've updated previous answer)
Such breakage is very rare in RHEL (and shouldn't have happened). BTW new features may happen in point release during active support phase 1 of RHEL)
So updating this "single" package will fix this issue (of course full update is preferred)
I think the EL AppStreams will better suit my requirements, even if these are a bit slower than i would wish for.
CentOS Stream is already on the way for update:
- 8.0.27 => https://gitlab.com/redhat/centos-stream/rpms/php/-/commits/c9s/
- 8.1.14 https://gitlab.com/redhat/centos-stream/rpms/php/-/commits/stream-php-8.1-rhel-9.2.0
So these updates will appear in RHEL, but in all cases, this will happen in 9.1 (security) or 9.2 (point release)
So the OS update should be a priority
For memory, I just add a new dependency to ensure pcre2 version used at runtime matches the one used at buildtime.
$ rpm -q --requires php-common | grep pcre
pcre2(x86-64) >= 10.40
This will forbid broken installation on EL 9.0