AC_PROG_CC NextStep failure

[Eric Sunshine]

Hello,

I have been battling for some time with a particularly inexplicable random  
failure of AC_PROG_CC on NextStep in the Autoconf 2.5x releases.  I finally  
tracked the problem down to an OS or I/O bug wherein up to 14 null bytes are  
inserted randomly (perhaps on 70% of my trials) at the head of the generated  
confdefs.h file.  The null bytes cause all tests to fail which utilize  
confdefs.h.  After approaching the problem from many different angles in an  
attempt to narrow it down as much as possible and devise a reasonable  
work-around, I ultimately arrived at the following patch for general.m4.

2003-11-16  Eric Sunshine  <address@hidden>

        * lib/autoconf/general.m4 (confdefs.h composition): Worked around a
        particularly inexplicable NextStep OS or I/O bug where up to 14 null
        bytes are incorrectly inserted at the head of the generated confdefs.h;
        thus causing all tests to fail which utilize confdefs.h.  Bug seems to
        be triggered by use of '>' (or 'touch') to create confdefs.h, followed
        by '>>' to augment it.  Bug manifests randomly about 70% of the time
        when config.log does not already exist before the configure script is
        invoked (that is, on an initial run of configure).  Bug manifests
        regardless of which Bourne shell is used (factory-supplied or recent
        Bash, for instance), and regardless of which commands are used to
        compose confdefs.h (cat versus echo, for example).  The simple
        work-around is to ensure that at least 14 valid bytes are written to
        confdefs.h when it is created initially via '>'.


--- lib/autoconf/general.m4     Sun Nov 16 19:32:43 2003
+++ ../general.m4-nextstep-fix  Sun Nov 16 19:31:43 2003
@@ -1202,8 +1202,33 @@

 # confdefs.h avoids OS command line length limits that DEFS can exceed.
 rm -rf conftest* confdefs.h
+
 # AIX cpp loses on an empty file, so make sure it contains at least a newline.
-echo >confdefs.h
+# Furthermore, work around a particularly obnoxious NextStep 3.3 (patch 3) bug
+# (and possibly earlier releases) where the OS inexplicably inserts up to 14
+# null bytes at the head of confdefs.h when it is created first via `>' (or
+# `touch') and then augmented via `>>' (which is exactly how confdefs.h is
+# composed).  The null bytes cause failure of all tests which subsequently
+# utilize confdefs.h.  A clue to the nature of the problem is that if the
+# initial `>', which creates the file, inserts 9 valid characters into the
+# file, then the OS will incorrectly insert 5 null bytes (9+5=14).  We can work
+# around this problem by ensuring that the initial `>' inserts at least 14
+# valid characters into the file, since 14 or more valid characters prevents
+# the OS from incorrectly inserting any null bytes.  This bug is particularly
+# inexplicable because it only manifests if the config.log file does not
+# already exist (that is, on an initial run of the configure script), and even
+# when it does manifest it only does so randomly; perhaps 70% of the time when
+# config.log does not yet exist.  The bug does not seem to be susceptible to
+# timing; that is, inserting a `sleep' delay at the point after configure
+# creates config.log does not eliminate the problem.  Nor is the problem
+# specific to the Bourne shell shipped with NextStep; it manifests both with
+# the shipped Bourne shell and with modern versions of Bash.  The problem does
+# not seem to be specific to either `echo' or `cat', since it continues to
+# manifest even when one command is swapped for the other.  Finally, using
+# `touch' to create confdefs.h initially, rather than `>', also fails to
+# eliminate the problem.  The above observations tend to point at this being an
+# OS- or I/O-specific bug.
+echo "/* This line is >=14 bytes to work around NextStep bug. */" >confdefs.h

 # Predefined preprocessor variables.
 AC_DEFINE_UNQUOTED([PACKAGE_NAME], ["$PACKAGE_NAME"],