Remove CPP when invoking dtrace utility #12083
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
|
I merged it. In case Remi finds another issue, we can always open a new PR... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see #11847). The issue is caused by inappropriate use C preprocessor detected by GNU Autoconf in our
configurescript. C preprocessor configuration found byAC_PROG_CPPmacro 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 ourconfigurescript.Many major Linux distributions use SystemTap to provide
dtraceutility. It relies on both external C preprocessor and external C compiler. C preprocessor can be customized viaCPPenvironment variable. Similarly, C compiler can be customized viaCCenvironment variable. It also allows customization of C compiler flags viaCFLAGSenvironment variable. We have recently aligned bothCPPandCCenvironment variable with C preprocessor and C compiler we use to build regular C source code as provided by ourconfigurescript (see #11643). We wanted to allow cross-compilation on Linux for which this was the only blocker. C compiler flags fromCFLAGS_CLEANmacro have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18.We had modified all
dtraceinvocations in the same way to make it look consistent. However, only the C compiler (CCenvironment 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 ofAC_PROG_CPPmacro 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 stabilizesdtraceinvocation on Linux systems with SystemTap and aligns it with other system configurations on other platforms, until someone comes with complete solution with customm4andmakemacros, while our build system on Linux with SystemTap supports cross-compilation.