[prev in list] [next in list] [prev in thread] [next in thread] 

List:       autoconf-bug
Subject:    Re: autoconf-2.65 on UnixWare 7.1.4
From:       Tim Rice <tim () multitalents ! net>
Date:       2010-01-25 0:25:01
Message-ID: Pine.UW2.4.64.1001241426010.23948 () server01 ! int ! multitalents ! net
[Download RAW message or body]

On Sun, 24 Jan 2010, Ralf Wildenhues wrote:

> * Tim Rice wrote on Mon, Jan 18, 2010 at 07:17:52PM CET:
> > On Sat, 16 Jan 2010, Ralf Wildenhues wrote:
> > > > > * Tim Rice wrote on Tue, Jan 12, 2010 at 01:48:43AM CET:
> > 
> > > > > > iASBOX
> > > > > > ......
> > > > > > 
> > > > > > I've seen this before back in autoconf-2.59.
> 
> > > Can you check whether that configure script has the problematic EOF
> > > marker crossing a 1024 byte boundary?
> > 
> > As you note below, the _ of the closing the _ASBOX marker is on a 1024
> > byte boundry.
> 
> > > I suspect that here-doc within here-doc is a red herring; but I'm not
> > > sure.  Can you check whether the problem disappears if, in the 2.65
> > > test, you change the one problematic EOF marker pair from _ASBOX to a
> > > different string with the same length?
> > 
> > Changing to a different string of the same length produces the same error.
> >  
> > > > I can add or subtract a space and get different results.
> 
> > > Which ksh version is this?
> 
> > Version M-12/28/93e-SCO
> 
> OK, thanks.  Let's see if this bug is easy to trigger.  Can you run the
> attached script, with $shell set to /bin/ksh or another suspect shell,
> and report its output?  It might take quite a while, so another option
> is to initialize $t with something a bit less than 1000 bytes and try
> fewer loops.

I could not get any failures.
/bin/ksh	Version M-12/28/93e-SCO on UnixWare 7.1.4 MP3
/bin/ksh	Version M-12/28/93e-SCO on UnixWare 7.1.4 MP4

/bin/ksh	Version M-12/28/93e-SCO on UnixWare 7.1.1 MP5
/bin/ksh88	Version M-11/16/88h on UnixWare 7.1.1 MP5

/bin/ksh	Version 11/16/88g on OpenServer 6 MP4
/bin/ksh93	Version M 1993-12-28 s+ on OpenServer 6 MP4

 
> If that doesn't expose the bug, then it might be that some earlier
> construct in the configure script cause the shell to corrupt internal
> data structures.  In that case the only easy strategy I can think of
> to try to delimit the issue would be to try shorter here-document EOF
> markers in one of the failing configure scripts (and varying the script
> length before the failure code manually) to see whether there is a
> minimum length where it fails.

I don't think I understand what you are proposing here.
 
I should also point out (for completeness) that I am using the ksh
from MP3 here because the one from MP4 is broken even worse.
About a year ago, I found my OpenSSH builds were failing after
installing MP4 because configure no longer found UnixWare's capabilities
correctly. Going back to the MP3 ksh solved this. In debugging the
problem we found that the length of the user's PATH could make the
difference between configure working or not.

-- 
Tim Rice				Multitalents	(707) 887-1469
tim@multitalents.net





[prev in list] [next in list] [prev in thread] [next in thread]