02b3fb1f6b
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 |
||
|---|---|---|
| .. | ||
| tests | ||
| config.m4 | ||
| config.w32 | ||
| CREDITS | ||
| LICENSE | ||
| oci8_arginfo.h | ||
| oci8_collection.c | ||
| oci8_dtrace.d | ||
| oci8_failover.c | ||
| oci8_interface.c | ||
| oci8_lob.c | ||
| oci8_statement.c | ||
| oci8.c | ||
| oci8.stub.php | ||
| package.xml | ||
| php_oci8_int.h | ||
| php_oci8.h | ||
| README.md | ||
The OCI8 Extension
Use the OCI8 extension to access Oracle Database.
Documentation is at https://www.php.net/oci8
Use pecl install oci8 to install for PHP 8.2.
Use pecl install oci8-3.2.1 to install for PHP 8.1.
Use pecl install oci8-3.0.1 to install for PHP 8.0.
Use pecl install oci8-2.2.0 to install for PHP 7.
The OCI8 extension can be linked with Oracle client libraries from Oracle Database 11.2 or later. These libraries are found in your database installation, or in the free Oracle Instant Client from https://www.oracle.com/database/technologies/instant-client.html Install the 'Basic' or 'Basic Light' Instant Client package. If building from source, then also install the SDK package.
Oracle's standard cross-version connectivity applies. For example, PHP OCI8 linked with Instant Client 19c can connect to Oracle Database 11.2 onward. See Oracle's note "Oracle Client / Server Interoperability Support" (ID 207303.1) for details.