When installing executables that were built using libtool, we are
supposed to use
$ libtool --mode-install <install-command>
rather than the bare <install-command>. This is discussed ever so
briefly in the "Installing executables" section of the GNU libtool
documentation:
https://www.gnu.org/software/libtool/manual/libtool.html
So far this has not caused a problem with GNU libtool on the platforms
that PHP supports, but there is an alternate libtool implementation
called slibtool that stores wrappers at the locations where PHP is
expecting the true executables to live. As a result, the wrappers (and
not the executables) are installed when slibtool is used to build PHP.
This is fixed by replacing,
$(INSTALL)
with
$(LIBTOOL) --mode=install $(INSTALL)
in the install-foo rules for the executables that are built with
libtool.
Closes GH-13674
This aligns the behaviour with what the stubs say.
And even if one fixes the stubs the behaviour is not identical due to missing indirect handling.
This indicates that using objects is never done, so do the easy fix of changing the ZPP specifier.
Closes GH-20465
The stubs say array so in debug mode we get a ZPP violation assertion and even by fixing the stubs the behaviour is not identical due to missing indirect handling.
This indicates using objects was never done, thus use the correct ZPP specifier
> LeakSanitizer has encountered a fatal error.
This happens only on 8.2/8.3 for some reason. Don't merge for 8.4 for now, we
can do that later if it reoccurs.
There have been misterious macOS failures with the following error for a long
time, which would usually happen 1-2x per nightly run:
> The hosted runner lost communication with the server. Anything in your
> workflow that terminates the runner process, starves it for CPU/Memory, or
> blocks its network access can cause this error.
After way too much debugging, it looks like this is caused by the two fpm tests
skipped in this commit. When there's a failure, the responsible test will run
for at least 120 seconds until the job is eventually killed by GitHub Actions.
It's not clear yet why the tests stall.
Debugging this is a PITA because the GitHub Actions log gets partially lost for
killed jobs. It took an external log server to actually figure out where the job
fails. Let's disable the tests first to be sure this actually solves the issue.
The fix fixes some other races that could result in mixed up copy and
nprocs number. It requires creating a copy in a similar way like for
request status.
This was not previously used to not impact other requests. However this
does not make that much sense as the only thing that impacts it is
holding the lock and not waiting for it. It is true that if there was a
big contention then the lock would be acquired more often but that can
be achieved by using fpm_get_status in loop so it should not make a
huge difference hopefully.
Closes GH-19974
This changes default for fastcgi.script_path_encoded INI to have
default behavior without a BC break. There has been already issue
about this in RC so it is very likely that it could have much bigger
impact so it's better to be safe.
In CGI, php_auto_globals_create_server() (i.e. auto_global_callback() here)
initializes $_ENV to reuse for $_SERVER. However, because $_SERVER is
constructed first, we have not yet initialized auto_global->armed of the $_ENV
global. Split the loop into initialization and constructor phases.
Fixes GH-19934
Closes GH-19870
This ensures that no useless "Failed to poll event" error messages are
logged during normal server operation, as the SOCK_EAGAIN error simply
indicates another worker is already serving the request.
Closes GH-19964
In CGI, php_auto_globals_create_server() (i.e. auto_global_callback() here)
initializes $_ENV to reuse for $_SERVER. However, because $_SERVER is
constructed first, we have not yet initialized auto_global->armed of the $_ENV
global. Split the loop into initialization and constructor phases.
Closes GH-19870
* main: Ignore `register_argc_argv` when `SG(request_info).argc` is available
* sapi: Remove hardcoded `register_argc_argv` for CLI SAPIs
This INI is ignored since the previous commit, which makes the hardcoded
setting obsolete.
* main: Deprecate deriving $_SERVER['argc'] and $_SERVER['argv'] from the query string
RFC: https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_the_register_argc_argv_ini_directive
* main: Adjust deprecation message for `register_argc_argv`
* NEWS/UPGRADING
