Re: non portable sed scripts

[Ralf Wildenhues]

Hi Paul,

* Paul Eggert wrote on Fri, May 19, 2006 at 11:04:52PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
> > We check the 99 commands limit, but
> > not the [4000] characters limit any more...  :-/
> 
> But the 4000-character limit is documented by Autoconf to be a limit
> on the length of lines of sed's input data, not a limit on the total
> size of the sed script.

D'oh.  I misread this section long ago and have always thought that
wrongly since...

So then the total limit of the script size I found on Solaris (described
in that other mail in this thread that was pending for some hours)
really is a new issue.

> However, it turns out that we check the 99 commands limit incorrectly,
> as the sed script in question contains 100 commands.  I installed this
> patch.  It's conceivable that this patch fixes the problem; it'd be
> nice to test this.

All my testing of seds a couple of months ago showed that labels do not
count as commands.  If you have a sed where this is different, then I'd
like to know.

> I found what appear to be some other off-by-one issues that cause
> 98-line scripts instead of 99, but these are not bugs so I didn't fix
> it.  Also, that code is too hairy (does anybody understand it other
> than its author? I sure don't) so I didn't want to mess with it.

It's pretty hairy.  I don't want to claim that I fully understand it,
but I did fix a couple of bugs in it.

> In the long run we're probably better off finding a working 'sed' than
> continuing to cater to broken ones.

FWIW, I agree.  Actually, it would probably be best to kill the
quadratic complexity in the number of AC_SUBSTs incurred by a sed script
and replace it by an awk script that searches for @[a-zA-Z][a-zA-Z0-9]*@
in the .in file and uses that variable name as key in a hash.

Cheers,
Ralf

Re: fetchmail-6.2.5 solaris 8 GNUCC

[Ralf Wildenhues]

Hi Jerry,

* Carlin, Jerry wrote on Fri, May 19, 2006 at 09:40:00PM CEST:
> 
> checking resolv.h presence... yes
> configure: WARNING: resolv.h: present but cannot be compiled
> configure: WARNING: resolv.h: check for missing prerequisite headers?
> configure: WARNING: resolv.h: proceeding with the preprocessor's result
> configure: WARNING: ##  ##
> configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
> configure: WARNING: ##  ##
> checking for resolv.h... yes
> checking net/socket.h usability... no

Thanks for reporting this.  Please read
  info Autoconf "Present But Cannot Be Compiled"

and then show that to the maintainer of the package you are compiling, who can
fix this in his package.

Cheers,
Ralf

Re: non portable sed scripts

[Tim Rice]

On Fri, 19 May 2006, Ralf Wildenhues wrote:

> Hi Tim,
> 
> * Tim Rice wrote on Fri, May 19, 2006 at 06:57:48PM CEST:
> > 
> > Autoconf version 2.59c
> > 
> > I had an opportunity to run a configure script generated with 2.59c
> > (ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.95.tar.gz) and found
> > that it failed.
> 
> > config.status: creating config.h
> > UX:sed: ERROR: Command garbled: HAVE_DECL_STRNDUP\)[ 
> > (].*$,\1define\2 0 ,
> 
> I'm pretty sure the syntax of the sed script is ok.  It's probably that
> your sed has a length restriction.  We check the 99 commands limit, but
> not the 2000 characters limit any more...  :-/
> 
> This particular sed script seems to have around 7200 characters before
> the failing line though.  So what's the limit on your system?

You may well be right.
Unknown, I don't have source. :-(

> 
> To get at the individual sed scripts for config.h:
> - in config.status, search for lines
> sed -f "$tmp/defines.sed" "$tmp/out..." >"$tmp/out..."
>   and rename the file "$tmp/defines.sed" afterwards, so it's not
>   overwritten by the next file.
> 
> - Then, watch
> sh -x ./config.status -d

Hmm, "sh -x ./config.status -d" generates a good config.h
The config.h generated at configure time had just the first line.

>   and look at the sed scripts.

They look fine.

[hours and much testing later]

It must be some obscure shell bug.
If I "ksh configure" it works fine.

To answer Paul's question, This is UnixWare 7.1.1
I don't see the problem on my UnixWare 7.1.4 box.
Even my old UnixWare 2.03 box does OK.

I'd say it's not a bug. Sorry for the noise.
 
> Boy, I hope this isn't so difficult to fix, with all that reworking done
> to the config.status code.
> 
> Cheers, and thanks for reporting this!
> Ralf
> 

-- 
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]

Re: non portable sed scripts

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Fri, May 19, 2006 at 08:42:46PM CEST:
> > 
> > I'm pretty sure the syntax of the sed script is ok.  It's probably that
> > your sed has a length restriction.

Well, Autoconf-2.59 has been using 38 lines per here document:
| # Maximum number of lines to put in a shell here document.
| # This variable seems obsolete.  It should probably be removed, and
| # only ac_max_sed_lines should be used.
| : ${ac_max_here_lines=38}

lib/autoconf/status.m4:
|   sed ${ac_max_here_lines}q conftest.defines >>$CONFIG_STATUS

2.59c uses 99 commands now (for CONFIG_HEADERS substitutions).

Neither have been computing the number of characters in the sed script.
So, probably 2.59 has just been lucky to produce short enough scripts.

FWIW, we may easily generate too long scripts for CONFIG_FILES as well
now: the 2.59 method did 48 substitutions per script (because it used
two commands per substitution), now we do 96.  I've see a couple of
real-world examples with more than 4000 bytes with 2.59c.

FWIW, on Solaris, /usr/ucb/sed errors out with scripts longer than 6810
characters, /usr/xpg4/bin/sed segfaults at some point (don't remember
the exact number), /bin/sed allows much longer scripts.  My testing on
Solaris always had /bin early in $PATH, thus did not expose this issue.

Cheers,
Ralf

fetchmail-6.2.5 solaris 8 GNUCC

[Carlin, Jerry]

checking resolv.h presence... yes
configure: WARNING: resolv.h: present but cannot be compiled
configure: WARNING: resolv.h: check for missing prerequisite headers?
configure: WARNING: resolv.h: proceeding with the preprocessor's result
configure: WARNING: ##  ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ##  ##
checking for resolv.h... yes
checking net/socket.h usability... no


jerry

two host environments

[Yoshinori K. Okuji]

Hello,

In the newer version of GRUB, I've beein using autoconf in a tricky way. We 
aim at building tools which run on an operating system (such as an installer) 
as well as building binary images/files which run on a boot environment (such 
as a boot sector). GRUB wants to support that the user can install a boot 
loader on a different type of system (e.g. installing GRUB for PC on 
SparcStation). 

This requires two compilers, for the tools and for the standalone binary, and 
similarly two sets of flags for the compilers. As far as I know, autoconf 
does not support this - at least not in an intuitive way. For now, I'm using 
"build" to specify the environment for the tools, and "host" to specify the 
environment for the standalone binary.

Clearly, this does not follow the convention defined by autoconf, but I don't 
know anything better. For example, the user can build GRUB twice, say, once 
for PC, and once for SparcStation. But this is redundant, since the user does 
not need the tools for PC or the standalone binary for SparcStation in the 
above case. Instead, we would like to build it only once, without building 
any unneeded binary. Suppose that GRUB does not support the bootstrap on 
SparcStation but supports running the tools on SparcStation. This is 
critical, because the user can still build GRUB successfully, even if GRUB 
does not fully support the user's environment.

Would you give us any suggestion or idea?

Thanks,
Okuji

Re: Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1

[Paul Eggert]

Re ,
Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> http://lists.gnu.org/archive/html/autoconf-patches/2006-04/msg00027.html
> ... broke this.
>
> I'm still wondering whether we should just simply revert both patches,
> ... and leave a cleanup of this section to the beginning of a development
> cycle of Autoconf, not to an end of it.

Stepan, what do you think?  If we can't fix the bug in fairly short
order I'm inclined to agree with Ralf.  I don't have time to look into
it myself right now, unfortunately.

Re: non portable sed scripts

[Paul Eggert]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> We check the 99 commands limit, but
> not the [4000] characters limit any more...  :-/

But the 4000-character limit is documented by Autoconf to be a limit
on the length of lines of sed's input data, not a limit on the total
size of the sed script.

However, it turns out that we check the 99 commands limit incorrectly,
as the sed script in question contains 100 commands.  I installed this
patch.  It's conceivable that this patch fixes the problem; it'd be
nice to test this.

I found what appear to be some other off-by-one issues that cause
98-line scripts instead of 99, but these are not bugs so I didn't fix
it.  Also, that code is too hairy (does anybody understand it other
than its author? I sure don't) so I didn't want to mess with it.

In the long run we're probably better off finding a working 'sed' than
continuing to cater to broken ones.

2006-05-19  Paul Eggert  <[EMAIL PROTECTED]>

* lib/autoconf/status.m4 (_AC_OUTPUT_HEADER): Fix off-by-one bug
that caused config.status to generate 100-command sed scripts; the
portable limit is 99.

--- lib/autoconf/status.m4  19 May 2006 04:14:13 -  1.102
+++ lib/autoconf/status.m4  19 May 2006 21:01:31 -
@@ -660,7 +660,7 @@ echo 's/ $//
 [s,^[   #]*u.*,/* & */,]' >>conftest.defines
 
 # Break up conftest.defines:
-ac_max_sed_lines=m4_eval(_AC_SED_CMD_LIMIT - 3)
+ac_max_sed_lines=m4_eval(_AC_SED_CMD_LIMIT - 4)
 
 # First sed command is: sed -f defines.sed $ac_file_inputs >"$tmp/out1"
 # Second one is:sed -f defines.sed "$tmp/out1" >"$tmp/out2"

Re: Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1

[Ralf Wildenhues]

[ Cc:ing bug-autoconf as this is a genuine bug IMHO. ]

Hi Tim,

Thanks for reporting this!

* Tim Kosse wrote on Fri, May 19, 2006 at 10:56:01AM CEST:
> Package: autoconf
> Version: 2.59.cvs.2006.05.13-1
> Severity: important
> 
> If crosscompiling an autotools based package with mingw for Windows
> using this autoconf version, the resulting executable misses the .exe
> extension.  Going back to autoconf-2.59a-9 solves the problem.
> 
> Steps to reproduce:
> - install the following additional packages: mingw32, automake1.9
> - Get a minimal autoconf/automake based project from 
> http://filezilla-project.org/codesquid/hello.tar.bz2
> - Execute the following commands:
>   tar -xjf hello.tar.bz2
>   cd hello
>   aclocal
>   autoconf
>   automake -a
>   ./configure --host=i586-mingw32msvc --target=i496-mingw32msvc
>   make
> 
> Expected results: hello.exe
> Actual results: hello

Confirmed.  The cleanup patch
http://lists.gnu.org/archive/html/autoconf-patches/2006-04/msg00027.html
(there's been one fix to it in the same thread) broke this.

I'm still wondering whether we should just simply revert both patches,
and then turn
|   # FIXME: I believe we export ac_cv_exeext for Libtool,
|   # but it would be cool to find out if it's true.  Does anybody
|   # maintain Libtool? --akim.

into
|   # We export ac_cv_exeext here because the latter test is not
|   # safe: cross compilers may not add the suffix if given an `-o'
|   # argument, so we may need to know it at that point already.
|   # Even if this section looks crufty: it has the advantage of
|   # actually working.

and leave a cleanup of this section to the beginning of a development
cycle of Autoconf, not to an end of it.

Cheers,
Ralf

Re: non portable sed scripts

[Paul Eggert]

Thanks for the bug report.  I suspect that the sed usage is portable
but that we are running into some limitation of your 'sed'
implementation.

Here is some further information that you can send that will help us
debug this.  (I don't have access to your platform so I can't debug
the problem directly.)

Which operating system are you using?  What does the shell command
"uname -a" output?  How about the shell command "type sed" or "which
sed"?

Please try patching your config.status file as follows:

--- config.status~  2006-05-19 12:02:29.0 -0700
+++ config.status   2006-05-19 12:04:44.0 -0700
@@ -1013,6 +1013,7 @@ ${ac_dA}HAVE_DECL_STRTOUL$ac_dB${ac_dC}1
 ${ac_dA}HAVE_DECL_STRTOULL$ac_dB${ac_dC}1$ac_dD
 ${ac_dA}HAVE_DECL_TTYNAME$ac_dB${ac_dC}1$ac_dD
 CEOF
+cp "$tmp/defines.sed" myscript.sed
 sed -f "$tmp/defines.sed" $ac_file_inputs >"$tmp/out1"
 # First, check the format of the line:
 cat >"$tmp/defines.sed" 

Re: non portable sed scripts

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Fri, May 19, 2006 at 08:37:06PM CEST:
> * Tim Rice wrote on Fri, May 19, 2006 at 06:57:48PM CEST:
> > 
> > Autoconf version 2.59c

> > config.status: creating config.h
> > UX:sed: ERROR: Command garbled: HAVE_DECL_STRNDUP\)[ 
> > (].*$,\1define\2 0 ,
> 
> I'm pretty sure the syntax of the sed script is ok.  It's probably that
> your sed has a length restriction.  We check the 99 commands limit, but
> not the 2000 characters limit any more...  :-/
*snip*

That should've been 4000 characters, as in autoconf.texi.

Sorry about that.

Re: non portable sed scripts

[Ralf Wildenhues]

Hi Tim,

* Tim Rice wrote on Fri, May 19, 2006 at 06:57:48PM CEST:
> 
> Autoconf version 2.59c
> 
> I had an opportunity to run a configure script generated with 2.59c
> (ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.95.tar.gz) and found
> that it failed.

> config.status: creating config.h
> UX:sed: ERROR: Command garbled: HAVE_DECL_STRNDUP\)[   (].*$,\1define\2 0 ,

I'm pretty sure the syntax of the sed script is ok.  It's probably that
your sed has a length restriction.  We check the 99 commands limit, but
not the 2000 characters limit any more...  :-/

This particular sed script seems to have around 7200 characters before
the failing line though.  So what's the limit on your system?

To get at the individual sed scripts for config.h:
- in config.status, search for lines
sed -f "$tmp/defines.sed" "$tmp/out..." >"$tmp/out..."
  and rename the file "$tmp/defines.sed" afterwards, so it's not
  overwritten by the next file.

- Then, watch
sh -x ./config.status -d
  and look at the sed scripts.

Boy, I hope this isn't so difficult to fix, with all that reworking done
to the config.status code.

Cheers, and thanks for reporting this!
Ralf

Re: getloadavg module broken

[Bruno Haible]

Jim Meyering wrote:
> That is because it's looking in the wrong place.
> This patch fixes the immediate problem

Indeed, thanks. But the bug is really in the AC_FUNC_GETLOADAVG macro in 
autoconf.
The macros
AC_FUNC_ERROR_AT_LINE, AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK,
AC_FUNC_MALLOC, AC_FUNC_MEMCMP, AC_FUNC_MKTIME, AC_FUNC_OBSTACK,
AC_FUNC_REALLOC, AC_FUNC_STRTOD, AC_FUNC_STRNLEN, AC_REPLACE_FNMATCH
are all able to call AC_LIBOBJ without additional hassles on the user.
AC_FUNC_GETLOADAVG is not.

I'd ask to remove these lines from the AC_FUNC_GETLOADAVG macro:
-
# Make sure getloadavg.c is where it belongs, at configure-time.
test -f "$srcdir/$ac_config_libobj_dir/getloadavg.c" ||
  AC_MSG_ERROR([$srcdir/$ac_config_libobj_dir/getloadavg.c is missing])
-
and to change AC_FUNC_GETLOADAVG so that it doesn't need to #include this
file at configure time.

Rationale: It's not autoconf's business to impose file name restrictions
on a project, nor to check file names at configure time. "configure" is
there to test a platform's and compiler's feature. Checking a project's
files integrity is the job of automake.

> may cause trouble for people who put the libobj directory elsewhere.
> If any of you know of such a package, please let me know.

There are many such packages:
  - gettext: both libgrep and lib (not just one directory).
  - libiconv: srclib.
  - libtasn1: gl
  - m4: gnu
  - gpg: gl
  - libksba: gl
  - prelude: libmissing
  ...

I can hack gnulib-tool to override AC_LIBOBJ and AC_REPLACE_FUNCS so that
it works with two different directories with .c files, but no workaround is
possible against hardcoded file checks in autoconf macros.

Bruno

Re: [GNU Autoconf 2.59d] testsuite: 202 failed

[Ralf Wildenhues]

Hi Paul,

* Paul Eggert wrote on Fri, May 19, 2006 at 06:15:11AM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
> > you need a different method in the config.status code to
> > detect whether you need to munge with $MKDIR_P for subdirectories,
> 
> Thanks for explaining that, and for the test case.  I installed this:

Thanks.  I simply failed to see such a nice and simple solution.
I installed this further patch to fix the failure Ralf Menzel reported.

Cheers,
Ralf

* lib/autoconf/programs.m4 (AC_PROG_MKDIR_P): Name temporary
variable `ac_d' instead of `d' to avoid infringing namespace.
Report by Ralf Menzel.

Index: lib/autoconf/programs.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/programs.m4,v
retrieving revision 1.53
diff -u -r1.53 programs.m4
--- lib/autoconf/programs.m413 May 2006 09:54:51 -  1.53
+++ lib/autoconf/programs.m419 May 2006 08:10:52 -
@@ -660,9 +660,9 @@
 if mkdir -p --version . >/dev/null 2>&1 && test ! -d ./--version; then
   MKDIR_P='mkdir -p'
 else
-  for d in ./-p ./--version
+  for ac_d in ./-p ./--version
   do
-test -d $d && rmdir $d
+test -d $ac_d && rmdir $ac_d
   done
   MKDIR_P="$ac_install_sh -d"
 fi