[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autobuild logs for Autoconf

From: Eric Blake
Subject: Re: autobuild logs for Autoconf
Date: Fri, 17 Sep 2010 17:15:49 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100907 Fedora/3.1.3-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.3

On 09/15/2010 12:09 PM, Ralf Wildenhues wrote:
Hi Eric,

I sent a bunch of logs to
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.
  [(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

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library

reply via email to

[Prev in Thread] Current Thread [Next in Thread]