On 09/15/2010 12:09 PM, Ralf Wildenhues wrote:
Hi Eric,
I sent a bunch of logs to http://autobuild.josefsson.org/autoconf/
for git Autoconf plus the two diffs below. The second is for
Solaris 2.6 whose compiler generates core files for one particular
configure test (don't remember which) which causes lots of spurious
test failures.
Actually, rather than ignoring '^core$' in statesave.m4, I'm thinking it
would be better to figure out _which_ configure test is causing the
compiler to dump core, and fix that macro to include 'core' in the list
of files it rm's, alongside *.o, *.exe, conftest*, etc. After all:
1) core files are the sign that something crashed. In the specific case
where we are probing for whether a crash happens, in order to know how
to avoid triggering it later, we also know to remove the core file (for
example, see c.m4 AC_PROG_CC_C_O). In all other cases, the existence of
a core file is the sign of a portability problem that we need to start
working around, and masking their existence in statesave.m4 makes this
harder to detect.
2) core files are not consistently named. There's 'core',
'core.program', 'pid.core', and even 'program.exe.stackdump' variants,
among others. Why should '^core$' be the only thing masked in statesave.m4?
+++ b/tests/statesave.m4
@@ -31,7 +31,7 @@
# directory, while avoiding yet another fork.
m4_defun([AC_STATE_SAVE],
[(set) 2>&1 | sort>state-env.$1
-ls | sed '/^at-/d;/^state-/d;/^config\./d
+ls | sed '/^at-/d;/^state-/d;/^config\./d;/^core$/d
h
:b
$b
--
Eric Blake [email protected] +1-801-349-2682
Libvirt virtualization library http://libvirt.org
