Re: getloadavg module broken
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: non portable sed scripts
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: non portable sed scripts
* 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
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 CEOF
Then run the command ./config.status, and then look at the contents
of myscript.sed. Does that file look OK? How does your myscript.sed
compare to my (attached), which does work for me? What is the output
of this command?
sed -f myscript.sed config.hin | diff -b config.hin -
Thanks.
/^[ ]*#[]*undef[][
]*[_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ][_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]*[
]*$/b def
/^[ ]*#[]*define[ ][
]*[_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ][_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]*[(
]/b def
b
:def
s/$/ /
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*PACKAGE_NAME\)[
(].*$,\1define\2 GNU coreutils ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*PACKAGE_TARNAME\)[
(].*$,\1define\2 coreutils ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*PACKAGE_VERSION\)[
(].*$,\1define\2 5.95 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*PACKAGE_STRING\)[
(].*$,\1define\2 GNU coreutils 5.95 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*PACKAGE_BUGREPORT\)[
(].*$,\1define\2 bug-coreutils@gnu.org ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*PACKAGE\)[(].*$,\1define\2
coreutils ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*VERSION\)[(].*$,\1define\2
5.95 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*_GNU_SOURCE\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*STDC_HEADERS\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_SYS_TYPES_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_SYS_STAT_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_STDLIB_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_STRING_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_MEMORY_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_STRINGS_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_INTTYPES_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_STDINT_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_UNISTD_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*__EXTENSIONS__\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*_POSIX_PTHREAD_SEMANTICS\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_UNAME\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_CHROOT\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_GETHOSTID\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*_FILE_OFFSET_BITS\)[
(].*$,\1define\2 64 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*PROTOTYPES\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*__PROTOTYPES\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_STRING_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_LONG_DOUBLE_WIDER\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_LONG_DOUBLE\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_PATHS_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_STROPTS_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_SYS_IOCTL_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_SYS_PARAM_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_SYS_RESOURCE_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_SYS_STATVFS_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_SYS_TIME_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_SYS_VFS_H\)[
(].*$,\1define\2 1 ,
s,^\([ ]*#[]*\)[^ ]*\([ ][ ]*HAVE_SYS_WAIT_H\)[
Re: non portable sed scripts
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
Re http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368012, 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.
two host environments
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
