Re: Autoconf 2.60a on UnixWare 7.1.4

[Tim Rice]

On Mon, 11 Sep 2006, Ralf Wildenhues wrote:

> * Tim Rice wrote on Mon, Sep 11, 2006 at 03:35:11AM CEST:
> > 
> > I got an opportunity to test 2.60a on UnixWare 7.1.4.
> 
> > --------< snip from test 168's config.status >-------
> > # Find out whether ``test -x'' works.  Don't use a zero-byte file, as
> > # systems may use methods other than mode bits to determine executability.
> > cat >conf$$.file <<_ASEOF
> > #! /bin/sh
> > exit 0
> > SESEOF
> > chmod +x conf$$.file
> 
> > I have no idea why SESEOF is there instead of _ASEOF
> > I had updated to m4-1.4.6 so just to make sure it wasn't a m4-1.4.6
> > problem, I went back to m4-1.4.4 and re-tested. Same problem.
> 
> The problem can't be with m4, because the configure script looks
> identical to the one generated on a sane system, only the generated
> config.status file is bogus at this position.  I assume another bug wrt.
> here-documents.  Let's see: the problem occurs on line 256 of the
> generated config.status script, near byte 6524.  This part is completely
> generated from the first here-document that contains config.status; it's
> delimited by \_ACEOF (thus no variable expansion within).
> 
> Does the bug go away when you insert 1 (2, 3) empty lines before the
> inner here-document in the configure script (i.e., before line 2003)?
> What if instead you just insert some bytes before (e.g., in the
> comment)?  Does the problem go away if you replace the inner
> here-document by
>   echo '#! /bin/sh
>   exit 0' >conf$$.file
> 
> And for those methods that work, could you retest, this time applying
> the change to autoconf/lib/m4sugar/m4sh.sh:_AS_TEST_PREPARE (it will
> cause changes to more than one point in the configure script)?

Applying this patch makes it work.
....
--- lib/m4sugar/m4sh.m4.old     2006-06-19 22:35:38.000000000 -0700
+++ lib/m4sugar/m4sh.m4 2006-06-19 22:35:38.000000000 -0700
@@ -1021,6 +1021,7 @@
 m4_defun([_AS_TEST_PREPARE],
 [# Find out whether ``test -x'' works.  Don't use a zero-byte file, as
 # systems may use methods other than mode bits to determine executability.
+
 cat >conf$$.file <<_ASEOF
 #! /bin/sh
 exit 0
....

In another e-mail, Paul suggests:
    So this very much looks like the same sort of problem that we already
    know that ksh has with here-documents and variables.  He might try
    uniformly replacing _ASEOF with FOOEOF (without making any other
    changes) and see whether the word gets munged to OEOEOF.

So I tried this patch (on a fresh tree). Tests passed.
....
--- lib/m4sugar/m4sh.m4.old     2006-06-19 22:35:38.000000000 -0700
+++ lib/m4sugar/m4sh.m4 2006-06-19 22:35:38.000000000 -0700
@@ -1021,10 +1021,10 @@
 m4_defun([_AS_TEST_PREPARE],
 [# Find out whether ``test -x'' works.  Don't use a zero-byte file, as
 # systems may use methods other than mode bits to determine executability.
-cat >conf$$.file <<_ASEOF
+cat >conf$$.file <<FOOEOF
 #! /bin/sh
 exit 0
-_ASEOF
+FOOEOF
 chmod +x conf$$.file
 if test -x conf$$.file >/dev/null 2>&1; then
   as_executable_p="test -x"
....

I'm not sure why this should make things work.

I had also tried doing a global s/_ASEOF/FOOEOF/ on configure and
lib/m4sugar/m4sh.m4 (the only 2 files that contained the pattern _ASEOF).
Tests passed.
...
277 tests behaved as expected.
9 tests were skipped.
...

I'll be out of the office the 12th - 18th.
I can do more testing when I return.

-- 
Tim Rice                                Multitalents    (707) 887-1469
address@hidden