DTrace enabled build is broken #11847
Labels
Comments
|
I confirm, a simple revert fix the build |
|
Thanks for finding this. I'll check it out soon. Pinging also @f4z4on if he knows what is happening here. |
|
We really should have a CI build which builds with DTrace. |
|
Perhaps related to CPP being defined as |
|
And by the way, if I remember correctly, the issue is that the “make” rule I mentioned above: Zend/zend_dtrace_gen.h: /Users/f4z4/Developer/PHP/php-src/Zend/zend_dtrace.d
CPP="$(CPP)" CC="$(CC)" CFLAGS="$(CFLAGS_CLEAN)" dtrace -h -C -s /Users/f4z4/Developer/PHP/php-src/Zend/zend_dtrace.d -o $@.bak && $(SED) -e 's,PHP_,DTRACE_,g' $@.bak > $@generates empty |
|
Another by the way, this is an issue with SystemTap. It should work with or without workaround with or without spaces in |
|
Thanks for the info. Wouldn't it be simpler to introduce something like DTRACE_CPP variable instead? That way the DTrace specific preprocessor can be set for cases that want that ( Edit: Something like this: diff --git a/build/php.m4 b/build/php.m4
index 921a78eb78..83e6aa9a85 100644
--- a/build/php.m4
+++ b/build/php.m4
@@ -2389,7 +2389,7 @@ dnl overwritten (Bug 61268).
$abs_srcdir/$ac_provsrc:;
$ac_bdir[$]ac_hdrobj: $abs_srcdir/$ac_provsrc
- CPP="\$(CPP)" CC="\$(CC)" CFLAGS="\$(CFLAGS_CLEAN)" dtrace -h -C -s $ac_srcdir[$]ac_provsrc -o \$[]@.bak && \$(SED) -e 's,PHP_,DTRACE_,g' \$[]@.bak > \$[]@
+ CC="\$(CC)" $DTRACE_CPP CFLAGS="\$(CFLAGS_CLEAN)" dtrace -h -C -s $ac_srcdir[$]ac_provsrc -o \$[]@.bak && \$(SED) -e 's,PHP_,DTRACE_,g' \$[]@.bak > \$[]@
\$(PHP_DTRACE_OBJS): $ac_bdir[$]ac_hdrobj
@@ -2409,12 +2409,12 @@ EOF
$ac_bdir[$]ac_provsrc.lo: \$(PHP_DTRACE_OBJS)
echo "[#] Generated by Makefile for libtool" > \$[]@
@test -d "$dtrace_lib_dir" || mkdir $dtrace_lib_dir
- if CPP="\$(CPP)" CC="\$(CC)" CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o $dtrace_d_obj -s $abs_srcdir/$ac_provsrc $dtrace_lib_objs 2> /dev/null && test -f "$dtrace_d_obj"; then [\\]
+ if CC="\$(CC)" $DTRACE_CPP CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o $dtrace_d_obj -s $abs_srcdir/$ac_provsrc $dtrace_lib_objs 2> /dev/null && test -f "$dtrace_d_obj"; then [\\]
echo "pic_object=['].libs/$dtrace_prov_name[']" >> \$[]@ [;\\]
else [\\]
echo "pic_object='none'" >> \$[]@ [;\\]
fi
- if CPP="\$(CPP)" CC="\$(CC)" CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o $ac_bdir[$]ac_provsrc.o -s $abs_srcdir/$ac_provsrc $dtrace_nolib_objs 2> /dev/null && test -f "$ac_bdir[$]ac_provsrc.o"; then [\\]
+ if CC="\$(CC)" $DTRACE_CPP CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o $ac_bdir[$]ac_provsrc.o -s $abs_srcdir/$ac_provsrc $dtrace_nolib_objs 2> /dev/null && test -f "$ac_bdir[$]ac_provsrc.o"; then [\\]
echo "non_pic_object=[']$dtrace_prov_name[']" >> \$[]@ [;\\]
else [\\]
echo "non_pic_object='none'" >> \$[]@ [;\\]
@@ -2426,7 +2426,7 @@ EOF
*)
cat>>Makefile.objects<<EOF
$ac_bdir[$]ac_provsrc.o: \$(PHP_DTRACE_OBJS)
- CPP="\$(CPP)" CC="\$(CC)" CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o \$[]@ -s $abs_srcdir/$ac_provsrc $dtrace_objs
+ CC="\$(CC)" $DTRACE_CPP CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o \$[]@ -s $abs_srcdir/$ac_provsrc $dtrace_objs
EOF
;;
diff --git a/configure.ac b/configure.ac
index 66503615ed..cfc3b77f3e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1043,6 +1043,10 @@ if test "$PHP_IPV6" != "no" && test "$ac_cv_ipv6_support" = yes; then
fi
dnl DTRACE checks. Note: this has to be done after SAPI configuration.
+AC_ARG_VAR([DTRACE_CPP],[Override default DTrace cpp preprocessor when using --enable-dtrace option])
+dnl
+AS_IF([test -z "$DTRACE_CPP"],[],[DTRACE_CPP="CPP=\"$DTRACE_CPP\""])
+
PHP_ARG_ENABLE([dtrace],
[whether to enable DTrace support],
[AS_HELP_STRING([--enable-dtrace],
diff --git a/ext/oci8/config.m4 b/ext/oci8/config.m4
index 883e272fb1..51b147a6c6 100644
--- a/ext/oci8/config.m4
+++ b/ext/oci8/config.m4
@@ -124,7 +124,7 @@ dnl overwritten (Bug 61268).
PHP_EXT_SRCDIR([oci8])/$ac_provsrc:;
$ac_bdir[$]ac_hdrobj: $ac_srcdir[$]ac_provsrc
- CPP="\$(CPP)" CC="\$(CC)" CFLAGS="\$(CFLAGS_CLEAN)" dtrace -h -C -s $ac_srcdir[$]ac_provsrc -o \$[]@.bak && \$(SED) -e 's,PHPOCI_,DTRACE_,g' \$[]@.bak > \$[]@
+ CC="\$(CC)" $DTRACE_CPP CFLAGS="\$(CFLAGS_CLEAN)" dtrace -h -C -s $ac_srcdir[$]ac_provsrc -o \$[]@.bak && \$(SED) -e 's,PHPOCI_,DTRACE_,g' \$[]@.bak > \$[]@
\$(OCI8_DTRACE_OBJS): $ac_bdir[$]ac_hdrobj
@@ -145,12 +145,12 @@ EOF
$ac_bdir[$]ac_provsrc.lo: \$(OCI8_DTRACE_OBJS)
echo "[#] Generated by Makefile for libtool" > \$[]@
@test -d "$dtrace_lib_dir" || mkdir $dtrace_lib_dir
- if CPP="\$(CPP)" CC="\$(CC)" CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o $dtrace_d_obj -s $ac_srcdir[$]ac_provsrc $dtrace_oci8_lib_objs 2> /dev/null && test -f "$dtrace_d_obj"; then [\\]
+ if CC="\$(CC)" $DTRACE_CPP CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o $dtrace_d_obj -s $ac_srcdir[$]ac_provsrc $dtrace_oci8_lib_objs 2> /dev/null && test -f "$dtrace_d_obj"; then [\\]
echo "pic_object=['].libs/$dtrace_prov_name[']" >> \$[]@ [;\\]
else [\\]
echo "pic_object='none'" >> \$[]@ [;\\]
fi
- if CPP="\$(CPP)" CC="\$(CC)" CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o $ac_bdir[$]ac_provsrc.o -s $ac_srcdir[$]ac_provsrc $dtrace_nolib_objs 2> /dev/null && test -f "$ac_bdir[$]ac_provsrc.o"; then [\\]
+ if CC="\$(CC)" $DTRACE_CPP CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o $ac_bdir[$]ac_provsrc.o -s $ac_srcdir[$]ac_provsrc $dtrace_nolib_objs 2> /dev/null && test -f "$ac_bdir[$]ac_provsrc.o"; then [\\]
echo "non_pic_object=[']$dtrace_prov_name[']" >> \$[]@ [;\\]
else [\\]
echo "non_pic_object='none'" >> \$[]@ [;\\]
@@ -162,7 +162,7 @@ EOF
AC_MSG_WARN([OCI8 extension: OCI8 DTrace support is not confirmed on this platform])
cat>>Makefile.objects<<EOF
$ac_bdir[$]ac_provsrc.o: \$(OCI8_DTRACE_OBJS)
- CPP="\$(CPP)" CC="\$(CC)" CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o \$[]@ -s $ac_srcdir[$]ac_provsrc $dtrace_oci8_objs
+ CC="\$(CC)" $DTRACE_CPP CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o \$[]@ -s $ac_srcdir[$]ac_provsrc $dtrace_oci8_objs
EOF
;;Edit 2: For example, passing the |
petk
added a commit
to petk/php-src
that referenced
this issue
Aug 1, 2023
The way the DTrace generates files depend on the given preprocessor. Without passing the CPP environment variable dtrace Python script uses the cpp by default. For systems where the CPP is set to something else, the generated files won't be created the same way, so instead the DTrace preprocessor can be overriden manually with the new DTRACE_CPP variable. For example: ./configure DTRACE_CPP="gcc -E -xc" Fixes #phpGH-11847
petk
added a commit
to petk/php-src
that referenced
this issue
Aug 1, 2023
The way DTrace generates files depend on the given preprocessor. Without passing the CPP environment variable dtrace Python script uses the cpp by default. For systems where the CPP is set to something else, the generated files won't be created the same way, so instead the DTrace preprocessor can be overriden manually with the new DTRACE_CPP variable. For example: ./configure DTRACE_CPP="gcc -E -xc" --enable-dtrace Fixes #phpGH-11847
petk
added a commit
to petk/php-src
that referenced
this issue
Aug 1, 2023
The way DTrace generates files depend on the given preprocessor. Without passing the CPP environment variable dtrace Python script uses the cpp by default. For systems where the CPP is set to something else, the generated files won't be created the same way, so instead the DTrace preprocessor can be overriden manually with the new DTRACE_CPP variable. For example: ./configure DTRACE_CPP="gcc -E -xc" --enable-dtrace Fixes phpGH-11847
petk
added a commit
to petk/php-src
that referenced
this issue
Aug 1, 2023
The way DTrace generates files depend on the given preprocessor. Without passing the CPP environment variable dtrace Python script uses the cpp by default. For systems where the CPP is set to something else, the generated files won't be created the same way, so instead the DTrace preprocessor can be overriden manually with the new DTRACE_CPP variable. For example: ./configure DTRACE_CPP="gcc -E -xc" --enable-dtrace Fixes phpGH-11847
|
I’ve accidentally deleted my long comment musing about possible causes and so on. With the newer information from previous comments, the only important bit that someone may need is, that a quick workaround for majority of cases is explicitly setting Or: |
f4z4on
added a commit
to f4z4on/php-src
that referenced
this issue
Aug 2, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† SystemTap, unlike Oracle DTrace, Open DTrace or their forks, relies on C compiler and preprocessor. We have recently aligned both of these with compiler and preprocessor we use to build regular C source code (see phpGH-11643).‡ We set CPP environment variable to the value of our CPP macro which defaults to C preprocessor detected by configure script. Similarly, we set CC environment variable to the value of our CC macro which defaults to C compiler detected by configure script. C compiler flags have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18. We have modified all dtrace invocations in the same way to make it look consistent. However, SystemTap dtrace needs C preprocessor only when it generates header files (-h option) with preprocessing (-C option). Similarly, it needs C compiler only when it generates object files with probe definitions (-G option). Before, we fix the issue itself, we stop setting all these environment variables when invoking dtrace. We set only those necessary for particular action: 1. When generating headers file (-h option) with the help of C preprocessor (-C option), we pass the C precessor the user chose or configure detected (CPP). 2. When generating object files with probes (-G option), we pass the C compiler and its flags the user chose or configure detected (CC and CFLAGS). We hope this code style inconsistency in dtrace invocation will actually be useful in that it allows simpler fix to the issue we are experiencing when building PHP with DTrace enabled with SystemTap. We believe this also makes clearer the fact this is a strange area of PHP build process and vendor-independent invocation of dtrace is tricky. Hopefully, if there is some future need to change how we define and build statically-defined traces, people will notice differences between uses for dtrace. Properly solving this would require implementing non-trivial m4 macros, which is probably not warranted given this affects 8 lines of make commands… Therefore, intentional code seems like the best next option. Please note, all of this is specific to SystemTap which is itself available only on Linux. Oracle DTrace, Open DTrace or their forks do not use environment variables (they ignore them). The same is true about -C option which is specific to SystemTap which is also ignored by other DTrace implementations. † php#11847 ‡ php#11643
f4z4on
added a commit
to f4z4on/php-src
that referenced
this issue
Aug 2, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† SystemTap, unlike Oracle DTrace, Open DTrace or their forks, relies on C compiler and preprocessor. We have recently aligned both of these with compiler and preprocessor we use to build regular C source code (see phpGH-11643).‡ We set CPP environment variable to the value of our CPP macro which defaults to C preprocessor detected by configure script. Similarly, we set CC environment variable to the value of our CC macro which defaults to C compiler detected by configure script. C compiler flags have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18. We had modified all dtrace invocation in the same way to make it look consistent. However, SystemTap dtrace needs C preprocessor only when it generates header files (-h option) with preprocessing (-C option). Similarly, it needs C compiler only when it generates object files with probe definitions (-G option). Therefore, we have recently stopped setting all these environment variables when invoking dtrace. We set only what is necessary for particular action. We hope this makes this fix simpler and clearer without introducing additional complexity to our build system. The cause of our issue is the fact that GCC preprocessor, when invoked via “gcc” binary, detects the language for preprocessing from source file extensions. Because DTrace probes and providers for statically-defined tracing are in files with “.d” extension, GCC detection fails because it probably thinks it is processing proper D programing language source code (somewhat different from what DTrace uses) which has no C-style preprocessing. People have noticed, because configure script on systems with GCC sets CPP make macro to “gcc -E”. Therefore practically everyone, who does not override C preprocessor, who is building PHP with DTrace enabled on Linux with SystemTap, experiences this issue. We force C language when passing C preprocessor as set by the user or detected by the configure script. SystemTap dtrace expects C language preprocessor because pragmas in D programming language used by DTrace are the same #pragma directives known from C and similar languages. We use -x option from GCC to force C. Other compilers suites and their preprocessors (most notably Clang) recognize this option too. Many probably do not. However, this issue is specific to SystemTap, which is itself specific to Linux and has to be build using the same compiler as Linux kernel, which only supports building using GCC-compatible compilers. We can definitely imagine someone building PHP with DTrace enabled using SystemTap and wanting to use compiler suite or preprocessor which is different from what they used to build SystemTap itself or their Linux kernel and which does not recognize -x option. However, we do not think it is reasonable to accommodate for such use case. Properly solving this would require implementing non-trivial m4 macros, which is probably not warranted given this affects 2 lines of make commands… This has no effect on Oracle DTrace, Open DTrace or any of their forks because they do not allow customization of preprocessor nor compiler. They simply ignore CPP, CC, and CFLAGS environment variables, so it does not matter what values we set there. Fixes phpGH-11847 † php#11847 ‡ php#11643
f4z4on
added a commit
to f4z4on/php-src
that referenced
this issue
Aug 2, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† SystemTap, unlike Oracle DTrace, Open DTrace or their forks, relies on C compiler and preprocessor. We have recently aligned both of these with compiler and preprocessor we use to build regular C source code (see phpGH-11643).‡ We set CPP environment variable to the value of our CPP macro which defaults to C preprocessor detected by configure script. Similarly, we set CC environment variable to the value of our CC macro which defaults to C compiler detected by configure script. C compiler flags have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18. We have modified all dtrace invocations in the same way to make it look consistent. However, SystemTap dtrace needs C preprocessor only when it generates header files (-h option) with preprocessing (-C option). Similarly, it needs C compiler only when it generates object files with probe definitions (-G option). Before, we fix the issue itself, we stop setting all these environment variables when invoking dtrace. We set only those necessary for particular action: 1. When generating headers file (-h option) with the help of C preprocessor (-C option), we pass the C processor the user chose or configure detected (CPP). 2. When generating object files with probes (-G option), we pass the C compiler and its flags the user chose or configure detected (CC and CFLAGS). We hope this code style inconsistency in dtrace invocation will actually be useful in that it allows simpler fix to the issue we are experiencing when building PHP with DTrace enabled with SystemTap. We believe this also makes clearer the fact this is a strange area of PHP build process and vendor-independent invocation of dtrace is tricky. Hopefully, if there is some future need to change how we define and build statically-defined traces, people will notice differences between uses for dtrace. Properly solving this would require implementing non-trivial m4 macros, which is probably not warranted given this affects 8 lines of make commands… Therefore, intentional code seems like the best next option. Please note, all of this is specific to SystemTap which is itself available only on Linux. Oracle DTrace, Open DTrace or their forks do not use environment variables (they ignore them). The same is true about -C option which is specific to SystemTap which is also ignored by other DTrace implementations. † php#11847 ‡ php#11643
f4z4on
added a commit
to f4z4on/php-src
that referenced
this issue
Aug 2, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† SystemTap, unlike Oracle DTrace, Open DTrace or their forks, relies on C compiler and preprocessor. We have recently aligned both of these with compiler and preprocessor we use to build regular C source code (see phpGH-11643).‡ We set CPP environment variable to the value of our CPP macro which defaults to C preprocessor detected by configure script. Similarly, we set CC environment variable to the value of our CC macro which defaults to C compiler detected by configure script. C compiler flags have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18. We had modified all dtrace invocation in the same way to make it look consistent. However, SystemTap dtrace needs C preprocessor only when it generates header files (-h option) with preprocessing (-C option). Similarly, it needs C compiler only when it generates object files with probe definitions (-G option). Therefore, we have recently stopped setting all these environment variables when invoking dtrace. We set only what is necessary for particular action. We hope this makes this fix simpler and clearer without introducing additional complexity to our build system. The cause of our issue is the fact that GCC preprocessor, when invoked via “gcc” binary, detects the language for preprocessing from source file extensions. Because DTrace probes and providers for statically-defined tracing are in files with “.d” extension, GCC detection fails because it probably thinks it is processing proper D programing language source code (somewhat different from what DTrace uses) which has no C-style preprocessing. People have noticed, because configure script on systems with GCC sets CPP make macro to “gcc -E”. Therefore practically everyone, who does not override C preprocessor, who is building PHP with DTrace enabled on Linux with SystemTap, experiences this issue. We force C language when passing C preprocessor as set by the user or detected by the configure script. SystemTap dtrace expects C language preprocessor because pragmas in D programming language used by DTrace are the same #pragma directives known from C and similar languages. We use -x option from GCC to force C. Other compilers suites and their preprocessors (most notably Clang) recognize this option too. Many probably do not. However, this issue is specific to SystemTap, which is itself specific to Linux and has to be build using the same compiler as Linux kernel, which only supports building using GCC-compatible compilers. We can definitely imagine someone building PHP with DTrace enabled using SystemTap and wanting to use compiler suite or preprocessor which is different from what they used to build SystemTap itself or their Linux kernel and which does not recognize -x option. However, we do not think it is reasonable to accommodate for such use case. Properly solving this would require implementing non-trivial m4 macros, which is probably not warranted given this affects 2 lines of make commands… This has no effect on Oracle DTrace, Open DTrace or any of their forks because they do not allow customization of preprocessor nor compiler. They simply ignore CPP, CC, and CFLAGS environment variables, so it does not matter what values we set there. Fixes phpGH-11847 † php#11847 ‡ php#11643
|
I'm copying my comments from pull request #11853 here. I've also submitted alternative pull request #11858. I guess it would be better to debate the merits here rather spreading it across many different places. Here are my comments:
|
f4z4on
added a commit
to f4z4on/php-src
that referenced
this issue
Aug 4, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† SystemTap, unlike Oracle DTrace, Open DTrace or their forks, relies on both external C compiler and external preprocessor. We have recently aligned both of these with compiler and preprocessor we use to build regular C source code (see phpGH-11643).‡ We set CPP environment variable to the value of our CPP macro which defaults to C preprocessor detected by configure script. Similarly, we set CC environment variable to the value of our CC macro which defaults to C compiler detected by configure script. 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 have modified all dtrace invocations in the same way to make it look consistent. However, SystemTap dtrace needs C preprocessor only when it generates header files (-h option) with preprocessing (-C option). Similarly, it needs C compiler only when it generates object files with probe definitions (-G option). External C preprocessor use via the -C option is actually common to dtrace implementations other than SystemTap even for actions other than generating header files. However, customization of C preprocessor differs widely between SystemTap and the rest of DTrace ecosystem (for example, no other implementation uses environment variables). Before, we fix the issue itself, we stop setting all these environment variables when invoking dtrace. We set only those necessary for particular action: 1. When generating headers file (-h option) with the help of C preprocessor (-C option), we pass the C processor the user chose or configure detected (CPP). No CC nor CFLAGS environment variables. 2. When generating object files with probes (-G option), we pass the C compiler and its flags the user chose or configure detected (CC and CFLAGS). No CPP environment variable. We hope this code style inconsistency in dtrace invocation will actually be useful in that it allows simpler fix to the issue we are experiencing when building PHP with DTrace enabled with SystemTap. We believe this also makes clearer the fact this is a strange area of PHP build process and vendor-independent invocation of dtrace is tricky. Hopefully, if there is some future need to change how we define and build statically-defined traces, people will notice differences between uses for dtrace. Properly solving this would require implementing non-trivial m4 macros, which is probably not warranted given this affects 8 lines of make commands… Moreover, such macros probably belong to a project like GNU Autoconf rather than to PHP. Therefore, intentional code seems like the best next option. Please note, all this is specific to SystemTap which is itself available only on Linux. Oracle DTrace, Open DTrace or their forks do not use environment variables (they ignore them). † php#11847 ‡ php#11643
f4z4on
added a commit
to f4z4on/php-src
that referenced
this issue
Aug 4, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† SystemTap, unlike Oracle DTrace, Open DTrace or their forks, relies on both external C compiler and external preprocessor. We have recently aligned both of these with compiler and preprocessor we use to build regular C source code (see phpGH-11643).‡ We set CPP environment variable to the value of our CPP macro which defaults to C preprocessor detected by configure script. Similarly, we set CC environment variable to the value of our CC macro which defaults to C compiler detected by configure script. 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, SystemTap dtrace needs C preprocessor only when it generates header files (-h option) with preprocessing (-C option). Similarly, it needs C compiler only when it generates object files with probe definitions (-G option). External C preprocessor use via the -C option is actually common to dtrace implementations other than SystemTap even for actions other than generating header files. However, customization of C preprocessor differs widely between SystemTap and the rest of DTrace ecosystem (for example, no other implementation uses environment variables). Therefore, we have recently stopped setting all these environment variables when invoking dtrace. We set only what is necessary for particular action. We hope it makes this fix simpler and clearer without introducing additional complexity to our build system. The cause of our issue is the fact that GCC preprocessor, when invoked via “gcc” binary, detects the language for preprocessing from source file extensions. Because DTrace probes and providers for statically-defined tracing are in files with “.d” extension, GCC detection fails because it probably thinks it is processing proper D programing language source code (somewhat different from what DTrace uses) which has no C-style preprocessing macros. People have noticed, because configure script on systems with GCC sets CPP make macro to “gcc -E”. Therefore practically everyone, who does not override C preprocessor to “cpp”, who is building PHP with DTrace enabled on Linux with SystemTap, experiences this issue. We force C language when passing C preprocessor as set by the user or detected by the configure script. D programs for DTrace commonly use C language preprocessor. This includes statically-defined tracing probes which can contain the same #pragma directives known from C and similar languages. We use -x option from GCC to force C. Other compilers suites and their preprocessors may recognize this option too (most notably Clang). Many probably do not. However, this issue is specific to SystemTap, which is itself specific to Linux and has to be build using the same compiler as Linux kernel, which only supports building using GCC-compatible compilers. This limitation of using only GCC-compatible compiler suite does not apply to applications with statically-defined tracing. We can definitely imagine someone building PHP with DTrace enabled using SystemTap and wanting to use compiler suite or preprocessor which is different from what they used to build SystemTap itself or their Linux kernel and which does not recognize the -x option. However, we do not think it is reasonable to accommodate for such use case. Properly solving this would require implementing non-trivial m4 macros, which is probably not warranted given this affects 2 lines of make commands… Moreover, such macros probably belong to a project like GNU Autoconf rather than to PHP. This has no effect on Oracle DTrace, Open DTrace or any of their forks because they do not allow customization of preprocessor nor compiler via environment variables. They simply ignore CPP, CC, and CFLAGS environment variables, so it does not matter what values we set there. Fixes phpGH-11847 † php#11847 ‡ php#11643
1 task
f4z4on
added a commit
to f4z4on/php-src
that referenced
this issue
Aug 30, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-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 phpGH-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 phpGH-11847 † php#11847 ‡ https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#index-AC_005fPROG_005fCPP-1 * php#11643
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
PHP Version
PHP 8.3.0beta2
Operating System
Fedora and RHEL
The text was updated successfully, but these errors were encountered: