Bug #1095
closedurcu's configure script mangles variables that it shouldn't
100%
Description
When tracking down what appears to be a bug in the m68k GCC optimizer, we needed to recompile urcu with specific options added to the compiler command line to be able to track down what happened. The first attempt at doing that was:
cd tests/benchmark; make CFLAGS=-save-temps test_urcu_defer.o
but that didn't trigger the bug, as expected. This is due to the fact that URCU mangles CFLAGS (and LDFLAGS) in its configure script, which it should not ever do. The automake man page has this to say about the matter:
‘CPPFLAGS’, ‘AM_CPPFLAGS’, and ‘mumble_CPPFLAGS’ are three variables
that can be used to pass flags to the C preprocessor (actually these
variables are also used for other languages like C++ or preprocessed
Fortran). ‘CPPFLAGS’ is the user variable (*note User Variables::),
‘AM_CPPFLAGS’ is the Automake variable, and ‘mumble_CPPFLAGS’ is the
variable specific to the ‘mumble’ target (we call this a per-target
variable, *note Program and Library Variables::).
(this talks about CPPFLAGS, but the same is true about CFLAGS and LDFLAGS; see https://www.gnu.org/software/automake/manual/automake.html#Flag-Variables-Ordering for the full story).
The configure.ac script has a few instances where CFLAGS and LDFLAGS are directly modified. Since configure stores the value of those variables in case the user runs configure with "CFLAGS=foo ./configure", this means you are storing a value for those variables in the makefile, and that then a call of the type of "make CFLAGS=-save-temps foo.o" does not work as expected.
Updated by Michael Jeanson about 7 years ago
I've submitted a patch: https://lists.lttng.org/pipermail/lttng-dev/2017-April/027030.html
Could you try it?
Thanks,
Michael
Updated by Michael Jeanson almost 7 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Applied in changeset userspace-rcu|9a79c612003362a97217613b7906a4782977d373.