bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoconf-2.65 on UnixWare 7.1.4


From: Ralf Wildenhues
Subject: Re: autoconf-2.65 on UnixWare 7.1.4
Date: Sat, 16 Jan 2010 13:03:38 +0100
User-agent: Mutt/1.5.20 (2009-10-28)

Hi Tim,

* Tim Rice wrote on Wed, Jan 13, 2010 at 03:28:49AM CET:
> On Tue, 12 Jan 2010, Ralf Wildenhues wrote:
> > * Tim Rice wrote on Tue, Jan 12, 2010 at 01:48:43AM CET:
> > > I have built one here and test 127 does pass with 
> > > CONFIG_SHELL=/opt/bin/bash
> > > so it looks like yet another ksh bug. Hopefully the UnixWare engineers
> > > will find some time to work on my support call about the ksh bugs.
> > 
> > OK, so one suitable recommendation for users of this system is to
> > install bash first.  Which bash version did you use, and does it pass
> > all of its testsuite and does
> >   make check TESTSUITEFLAGS=CONFIG_SHELL=/path/to/bash
> > 
> > pass all of Autoconf's test suite?
>  
> The bash I built back in 2006 was version 3.1.17(1)-release
> With that we get testsuite: 74 211 failed
> I started working on building bash-4.1 last night.
> When I get that built, I'll see if it works any better.

Thanks.  I'd be interested in the global testsuite.log file, for both of
these shells (edit out confidential information if you need to).

> > > I've attached the full config.status but the interesting part is here.
> > 
> > It seems you've attached the file after applying your proposed patch
> > below.  Please attach the file for the original 2.65 code, unmodified
> > (gzip'ed is probably best to avoid transmission mangling).  It is
> > otherwise difficult to find out whether there might be another bug
> > lingering like the 1024-byte boundary ${var} expansion problem seen with
> > some older ksh versions.  Thanks.
> 
> Sorry about that. I thought my mail client had read in the attachment
> before I went and tested the changes. 
> Note to self: When using pine, postpone the message and then open again
> before modifying any attached documents.

If you know about it, it's a feature not a bug: you can edit the
attachment after noting it as such.  (My mailer works similarly.)

[...]
> > > iASBOX
> > > ......
> > > 
> > > I've seen this before back in autoconf-2.59.
> > 
> > At this very same spot only, or with other here-documents or other code
> > lines as well?
> 
> I remember having problems with OpenSSH's configure back when we used
> autoconf-2.59 to generate it.

Can you check whether that configure script has the problematic EOF
marker crossing a 1024 byte boundary?

> > But what is the problem really?  Is it here-doc EOF markers used both in
> > a shell script as well as in a here-doc in that shell script?  Or is it
> > here-docs of a certain size, or with certain contents?  Without
> > understanding that, we cannot know if the workaround is effective or
> > we'll introduce another similar issue in 2.66.
> 
> I've also attached the config.status from autoconf-2.59 test 063 that
> shows the problem.

autoconf-2.65/tests/testsuite.dir/226/inner/configure and
autoconf-2.59/tests/testsuite.dir/063/configure both
have in common that a 1024-byte boundary lies at the start of, or
inside, the _ASBOX marker.

> I don't really know what the problem is. It seems to be if there are
> here-doc within a here-doc in a shell script of a certain size
> with certain contents.

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?

> I can add or subtract a space and get different results.

Thanks for these tests.  Indeed sounds very similar to the bug we
documented in the long paragraph in
  info Autoconf Here-Documents

Which ksh version is this?  (Do 'set -o emacs' and then CTRL-V inside
ksh to find out.)

* Tim Rice wrote on Fri, Jan 15, 2010 at 06:56:30AM CET:
> On Tue, 12 Jan 2010, Tim Rice wrote:
> > 
> > Unfortunatly we're already selecting the best (least tests fail) shell
> > that ships with the system.
> > /bin/sh will pass test 127 (and 226) but fails 123 133 134 and 211.
> 
> Now I'm not so sure.
>  
> > I started working on building bash-4.1 last night.
> > When I get that built, I'll see if it works any better.
> 
> I re-ran test 127 with
>    gmake check TESTSUITEFLAGS='-v -d -x 127 CONFIG_SHELL=/bin/sh'
> and
>    gmake check TESTSUITEFLAGS='-v -d -x 127 CONFIG_SHELL=/opt/bin/bash'
> 
> See attached sh-testsuite.log.gz and bash-4.1-testsuite.log.gz
> In both cases the inner tests fail but the last line says test 127 is ok.
> Strange.

The inner tests 4-6 are supposed to fail.  It is a bug if they pass.

> At least ksh says 127 failed.

Well yes, that's the ksh issue with output not ending with a newline.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]