We are experiencing an issue when building PHP with DTrace enabled with
SystemTap (see GH-11847).† The issue is caused by inappropriate use C
preprocessor detected by GNU Autoconf in our “configure” script. C
preprocessor configuration found by AC_PROG_CPP macro is portable only
to run on files with “.c” extension.‡ However, statically-defined tracing
is described by D programs with “.d” extension which causes the issue.
We experience this even on typical Linux distribution with GNU Compiler
Collection (GCC) unless we override the defaults detected by our
“configure” script.
Many major Linux distributions use SystemTap to provide “dtrace”
utility. It relies on both external C preprocessor and external C
compiler. C preprocessor can be customized via CPP environment variable.
Similarly, C compiler can be customized via CC environment variable. It
also allows customization of C compiler flags via CFLAGS environment
variable. We have recently aligned both CPP and CC environment variable
with C preprocessor and C compiler we use to build regular C source code
as provided by our “configure” script (see GH-11643).* We wanted to
allow cross-compilation on Linux for which this was the only blocker. C
compiler flags from CFLAGS_CLEAN macro have already been in place since
versions 5.4.20 and 5.5.4 from 2013-09-18.
We had modified all “dtrace” invocations in the same way to make it look
consistent. However, only the C compiler (CC environment variable) is
necessary to for cross-compilation. There have never been any reported
issue with the C preprocessor. We acknowledge it would be great to allow
C preprocessor customization as well. However, the implementation would
require a lot of effort to do correctly given the limitations of
AC_PROG_CPP macro from GNU Autoconf. This would be further complicated
by the fact that all DTrace implementations, not just SystemTap, allow C
preprocessor customization but Oracle DTrace, Open DTrace, and their
forks do it differently. Nevertheless, they all default to “cpp” utility
and they all have or had been working fine. Therefore, we believe simply
removing CPP stabilizes “dtrace” invocation on Linux systems with
SystemTap and aligns it with other system configurations on other
platforms, until someone comes with complete solution with custom “m4”
and “make” macros, while our build system on Linux with SystemTap
supports cross-compilation.
Fixes GH-11847
Closes GH-12083
† https://github.com/php/php-src/issues/11847
‡ https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#index-AC_005fPROG_005fCPP-1
* https://github.com/php/php-src/issues/11643
Most oci8 tests fail out-of-the-box because a typical host won't have
an Oracle database instance available. Other database drivers like
mysqli and pgsql address this problem with an include file, inserted
into SKIPIF, that skips the test if no connection at all can be made.
This commits adds such a file (skipifconnectfailure.inc) for oci8, and
adds the corresponding SKIPIF to any tests that connect to a database.
Closes GH-11804
* ext/oci8/tests/lob_aliases.phpt: drop unnecessary SKIPIF.
With DTrace support enabled during ./configure, our custom Autoconf
macro PHP_INIT_DTRACE creates make rules to generate header and object
files using dtrace utility. SystemTap† implementation of dtrace relies
on other utilities to provide header preprocessing and final object file
compilation. These utilities are configured by common environment
variables with common defaults:‡
* preprocessor from CPP defaults to “cpp”
* compiler from CC defaults to “gcc”
* compiler arguments can be expanded with CFLAGS
This has been in SystemTap since version 1.5 released on 2011-05-23. We
have been setting CFLAGS for dtrace since 717b367 released in versions
5.4.20 and 5.5.4 on 2013-09-18. This change fixed build against
SystemTap. It fixes majority of cases since practically all free Linux
distributions use SystemTap for DTrace-like dynamic tracing and
practically all of them use GCC or compatible compiler suite. However,
this becomes an issue when cross-compiling using GCC because utility
names contain target triplets. Autoconf already handles
cross-compilation well —setting correct CC and CPP make macros
(variables).
Therefore, we simply set CC and CPP environment variables using
respective macros when executing dtrace. Although SystemTap dtrace does
not always use CC nor CPP, we set it every time. SystemTap documentation
does not talk about this at all¶, so it is safer to always set it. We
also follow how we set CFLAGS every time in the past.
Original (or ported) DTrace mainly used on Oracle Linux, Solaris and
macOS ignores these and does not support cross compilation.§
† Well-known dynamic tracing infrastructure for Linux compatible with
statically-defined tracing from DTrace.
‡ https://sourceware.org/git/?p=systemtap.git;a=blob;f=dtrace.in;h=73a6f22e2de072773c692e3fea05c4b8cf814e43;hb=ebb424eee5599fcc131901c0d82d0bfc0d2f57ab
¶ https://sourceware.org/systemtap/man/dtrace.1.html
§ https://docs.oracle.com/cd/E88353_01/html/E72487/dtrace-8.html
Closes GH-11643
Fix GH-8756 : oci_new_descriptor() triggers dynamic property
deprecation.
This fix should be temporary. At some point we should either define
those properties or just hide them since they should probably not be
used.
Better fix is here : https://github.com/php/php-src/pull/8758 but
waiting feedback from Oracle team before going ahead.
* ext/oci8: use zend_string_equals()
Eliminate duplicate code.
* main/php_variables: use zend_string_equals_literal()
Eliminate duplicate code.
* Zend/zend_string: add zend_string_equals_cstr()
Allows eliminating duplicate code.
* Zend, ext/{opcache,standard}, main/output: use zend_string_equals_cstr()
Eliminate duplicate code.
* Zend/zend_string: add zend_string_starts_with()
* ext/{opcache,phar,spl,standard}: use zend_string_starts_with()
This adds missing length checks to several callers, e.g. in
cache_script_in_shared_memory(). This is important when the
zend_string is shorter than the string parameter, when memcmp()
happens to check backwards; this can result in an out-of-bounds memory
access.
