You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
0 commit comments