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 <sunshine@xxxxxxxxxxxxxx> * 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"],
