Hi Marc,
> the build-aux/run-test script recommends that the package is
> configured with "--disable-shared" "so that tests are real executables
> and not libtool wrapper scripts".
Yep. If you compile with --enable-shared and then run valgrind
on the wrapper scripts, the logs would contain output about the
sh or bash process, which is not what the user wants.
> I wonder why the script doesn't use the "libtool --mode execute
> valgrind ..." approach
Because we don't know where 'libtool' is. It could be in "..",
or in "../..", or in "../../..", and so on. It depends on the
package's directory structure.
By the way, the suggested invocation of valgrind (both in run-test
and in your GNOME link) causes valgrind to output its logs, but it
does not fail when there is a memory error. So, you would run "make check",
and that would succeed, despite the memory errors. This patch corrects the
suggestion:
2025-07-23 Bruno Haible <br...@clisp.org>
run-test: Suggest a more reliable way of invoking valgrind.
* build-aux/run-test (func_usage): Suggest to use the --error-exitcode
option.
diff --git a/build-aux/run-test b/build-aux/run-test
index de8678dc3c..53167320c3 100755
--- a/build-aux/run-test
+++ b/build-aux/run-test
@@ -31,6 +31,8 @@ Usage: run-test [OPTION...] CHECKER PROGRAM [ARGUMENT...]
Runs PROGRAM under the control of CHECKER.
CHECKER may be empty or a valgrind command with some options, such as
+'valgrind --tool=memcheck --error-exitcode=9 --num-callers=20'
+or
'valgrind --tool=memcheck --num-callers=20 --leak-check=yes
--leak-resolution=high --show-reachable=yes'.
When CHECKER is not empty, it is recommended that the package has been
