Hello,
On Tue, May 23, 2006 at 10:43:22AM +0200, Ralf Wildenhues wrote:
> | s,^\([ ]*#[ ]*\)[^ ]*\([ ][ ]*HAVE_DECL_NANOSLEEP\)[
> (].*$,\1define\2 0 ,
> | s,^\([ ]*#[ ]*\)[^ ]*\([ ][ ]*HAVE_DECL_REALLOC\)[
> (].*$,\1define\2 1 ,
> | s,^\([ ]*#[ ]*\)[^ ]*\([ ][ ]*HAVE_DECL_STPCPY\)[
> (].*$,\1define\2 0 ,
> | HAVE_DECL_STRNDUP\)[ (].*$,\1define\2 0 ,
> | s,^\([ ]*#[ ]*\)[^ ]*\([ ][ ]*HAVE_DECL_STRNLEN\)[
> (].*$,\1define\2 0 ,
> [...]
>
> So I assume we have an incarnation of a bug similar to this one
> (quoting `info Autoconf "Here-Documents"'):
>
> | Many older shells (including the Bourne shell) implement
> | here-documents inefficiently. And some shells mishandle large
> | here-documents: for example, Solaris `dtksh', which is derived from
> | Korn shell version M-12/28/93d, mishandles variable expansion that
> | occurs on 1024-byte buffer boundaries within a here-document. Users
> | can generally fix these problems by using a faster or more reliable
> | shell, e.g., by using the command `CONFIG_SHELL=/bin/bash /bin/bash
> | ./configure' rather than plain `./configure'.
you are so bright, Ralf!
> [...] Otherwise, I don't see much
> choice other than to suggest passing a more reliable shell.
Of course there is a general solution: we can actively test the shell
for this problem, in the ``detect better shell'' routine.
But this will enlarge the generated script by a kilobyte :-O
Have a nice day,
Stepan
