On Sun, 2018-08-05 at 15:55 -0700, Samuel Sieb wrote:
On 08/05/2018 01:13 PM, Florian Weimer wrote:
> There already is such a macro, %{valgrind_arches}, but it may not
> accurately reflect the suitability of the run-time behavior of valgrind
> on a particular architecture. For example, the undefinedness tracking
> might not be sufficiently accurate for the testsuite of a specific
> package, so running the testsuite under valgrind gives false positives.
So the original post is only to be used for specific exceptional cases?
Yes, Florian was just being very thorough.
We noticed packages disabled valgrind support on different
architectures for 2 different reasons.
It was disabled based on which architectures the package thought
valgrind was available for. If you just need to enable/disable valgrind
support because of this then please just use the %{valgrind_arches}
macro instead of hardcoding an architecture list in your package. The
macro will be updated whenever valgrind gets support for a new
architecture (or if an architecture is not longer completely supported,
it will be removed from this macro).
Secondly there might be a bug in valgrind on a particular architecture
that is triggered by something specific in the package. In that case
please use the construct Florian suggested to enable support based on
the %{valgrind_arches} macro with some package specific exception for
that particular architecture. And please file a bug against valgrind,
so it might get fixed.
Cheers,
Mark