Re: proposed patch for "Tests failed with LINENO." Autoconf bug

[Akim Demaille]

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

Paul> I verified that my bug does not occur if I use 5.005_03 instead
Paul> of 5.005_02.  So requiring Perl 5.005_03 or later seems like a
Paul> good idea.  Is that easy to do?

Yep:

|  % perl -e 'require 5.005_03;'                           nostromo 12:07
|  % perl --version                                        nostromo 12:25
| 
| This is perl, v5.6.1 built for i386-linux
| 
| Copyright 1987-2001, Larry Wall
| 
| Perl may be copied only under the terms of either the Artistic License or the
| GNU General Public License, which may be found in the Perl 5 source kit.
| 
| Complete documentation for Perl, including FAQ lists, should be found on
| this system using `man perl' or `perldoc perl'.  If you have access to the
| Internet, point your browser at http://www.perl.com/, the Perl Home Page.
| 
| % perl -e 'require 5.006_03;'                           nostromo 12:25
| Perl v5.6.30 required--this is only v5.6.1, stopped at -e line 1.

configure.ac needs to be adjusted (and in fact lib/Autom4te/General.pm
should have it too).  I found the message from Gary, the problem he
had was with 5.005_03:

| From: "Gary V. Vaughan" <address@hidden>
| Subject: IO::File with perl 5.005_03
| To: address@hidden
| X-Sent: 6 weeks, 3 days, 9 hours, 18 minutes, 9 seconds ago
| 
|  $ cd ~/devel/savannah/libtool-1-4/libltdl
|  $ automake
|  Can't call method "close" on an undefined value at
|  /usr/local/bin/automake line 7751.
|  $ automake --version
|  automake (GNU automake) 1.5
|  Written by Tom Tromey <address@hidden>.
|  
|  Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
|  Free Software Foundation, Inc.
|  This is free software; see the source for copying conditions.  There is NO
|  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|  $ cat -n /usr/local/bin/automake | sed '7745,7752p;d'
|    7745  # Ensure a file exists.
|    7746  sub create
|    7747  {
|    7748      my ($file) = @_;
|    7749
|    7750      my $touch = new IO::File (">> $file");
|    7751      $touch->close;
|    7752  }
|  $ sed '7750s/(">> \$file")/"$file", O_APPEND/' /usr/local/bin/automake > arse
|  $ chmod +x arse
|  $ sudo cp -f arse /usr/local/bin/automake
|  $ automake
|  
| I have no idea why this works, and the original doesn't.  I simply
| copied one of the examples from the IO::File perldocs which seems to
| fix it for me.
| 
| Cheers,
|       Gary.

But since Gary provides a workaround, that shouldn't matter.

Paul> I also verified that pascal.bart's bug does not occur if I
Paul> install Bash 2.04 as /bin/bash (which causes CONFIG_SHELL to
Paul> equal /bin/bash rather than /bin/ksh).  So this seems to be a
Paul> compatibility issue with Solaris 2.5.1 /bin/ksh.

Paul> I looked into the problem a bit more, and traced it down to two
Paul> different bugs:

Paul> 1. The awk solution that substitutes $LINENO does not work for
Paul> the "testsuite" command.  Some occurrences of the string
Paul> "$LINENO" in "testsuite" should not be substituted for, because
Paul> "testsuite" wants the string to not be evaluated by "testsuite"
Paul> itself, but by a subsidiary process.

Eeek :(

Paul> 2. The LINENO test in "testsuite" is too stringent; it rejects
Paul> Solaris 2.5.1 /bin/ksh even though /bin/ksh has adequate LINENO
Paul> support.  The problem is that Solaris 2.5.1 /bin/ksh does not
Paul> increment $LINENO inside an eval'ed string.  But Autoconf does
Paul> not rely on that particular feature (nor is it clear to me that
Paul> the 2.5.1 behavior is incorrect, and frankly I'm puzzled that we
Paul> haven't run into this problem elsewhere).  Anyway, we shouldn't
Paul> test for it.

Very much agreed, that was not meant.

Paul> Here is a patch for (2); it fixes pascal.bart's bug for me on
Paul> Solaris 2.5.1, and "make check" succeeds cleanly.

Thanks a lot Paul.  If you have some spare time to add information to
the documentation...

Paul> (As you know, I'm dubious about the 'awk' approach because I
Paul> think we'll keep running into problems with it, but please feel
Paul> free to fix (1) if you like.  :-)

:)

I'll fix that, thanks!