[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Paul Eggert]

Update of sr #110657 (project autoconf):

Priority: 3 - Low => 1 - Later  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Zack Weinberg]

Follow-up Comment #4, sr #110657 (project autoconf):

For the record, despite this having been marked "won't do", I _would_ consider
and review a patch (against current development trunk) that would make
configure scripgs set $EGREP and $GREP to `egrep` on systems where `egrep -e`
works but `grep -E -e` doesn't work.  It's just that neither Paul nor I have
the time, nor the necessary test environment, to develop such a patch.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Paul Eggert]

Update of sr #110657 (project autoconf):

  Status:   Need Info => Wont Do

___

Follow-up Comment #3:

OK, I think I see what's happening now; you have an egrep that's good enough,
but you also want to test for header files and Autoconf's header-file tests
insist on robust 'grep' because they prefer to use 'grep -E', as egrep was
removed from POSIX a long time ago.

For this sort of thing, I suggest either (a) installing and using a better
'grep' like GNU grep, or (b) running something like './configure
ac_cv_path_GREP=/usr/bin/grep ac_cv_path_egrep=/usr/bin/egrep' in the hopes
that your system grep and egrep are good enough for 'configure'. (a) should be
much better in the long run.

I doubt whether we should modify Autoconf to work around this problem, as it
should occur only on nonstandard platforms that are no longer supported even
by their own suppliers.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110660] AC_LANG_INT_SAVE (used by AC_CHECK_SIZEOF) includes stdlib.h without checking whether it actually exists

[Paul Eggert]

Update of sr #110660 (project autoconf):

Priority:  5 - Normal => 3 - Low
Severity:  3 - Normal => 1 - Wish   

___

Follow-up Comment #3:

> This fails if stdlib.h doesn't actually exist.
Yes, and that's documented behavior. The Autoconf manual says:

> If your program needs to be portable to a _freestanding_
> environment, such as an embedded OS that doesn't provide all of the
> facilities of the C90 standard library, you may need to test for some of
> the above headers as well.  Note that many Autoconf macros internally
> assume that the complete set of C90 headers are available.
It'd be nice if Autoconf also worked for freestanding programs too. That'd
require a bit of work though. In the meantime I'll mark this as a wishlist
item.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110655] AT UnixPC (3b1) shell thrown off by #( after case.

[Alain Knaff]

Follow-up Comment #5, sr #110655 (project autoconf):


[comment #3 comment #3:]
> This is also code that no longer exists in current versions of Autoconf,
which instead unconditionally set
> 
> as_echo='printf %s\n'
> as_echo_n='printf %s'
> 

Not sure whether that is a good thing in the context of this bug, as UnixPC
does not contain a printf shell command... (But as it is mostly a wrapper
around the printf C function, it could probably be rigged up quite easily)


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110660] AC_LANG_INT_SAVE (used by AC_CHECK_SIZEOF) includes stdlib.h without checking whether it actually exists

[Alain Knaff]

Follow-up Comment #2, sr #110660 (project autoconf):


[comment #1 comment #1:]
> You've been filing all of these bugs -- exactly which version of Autoconf
are you using to generate the configure scripts that show these bugs?

I'm using 2.69-14, currently included with Debian 11.

>  Some of the things you have said (e.g. talking about configure.in instead
of configure.ac) suggest that you are using a *very old* version of Autoconf.

Indeed, I just noticed that this is 10 years old, and that there have been 2
new releases last year.

Sorry for not having noticed that earlier.

I'll continue my tests with the new version... Don't expect fast updates to my
other bugs though, as a full run of configure takes between 2 and 3 hours... 


> 
> The code generated for AC_CHECK_SIZEOF, in current versions of autoconf, is
completely different from the code you quoted, and does not make any use of
either stdio.h or stdlib.h, so the bug seems moot to me.
> 
> (N.B. Current versions of autoconf do not support pre-C89 compilers. 
However, the bug report is abstractly valid anyway, because a "freestanding"
C89 compiler doesn't have to provide stdio.h and stdlib.h.)

The compiler included with the UnixPC image I'm using is gcc 2.5.8 if that
helps.
UnixPC also has a "native" cc compiler, but that one is unusable for the
purpose as it is Kernighan syntax (no types in prototype)


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110655] AT UnixPC (3b1) shell thrown off by #( after case.

[Zack Weinberg]

Follow-up Comment #4, sr #110655 (project autoconf):

That said, the observation that even current shells will choke on `eval` of
shell variables containing long runs of shell code including comments, is
valuable.  That's something we should be avoiding in general and not just in
this case.

(We should be trying to move away from shell variables containing shell code,
period.  That's what shell functions are for.)


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110655] AT UnixPC (3b1) shell thrown off by #( after case.

[Zack Weinberg]

Follow-up Comment #3, sr #110655 (project autoconf):

This is also code that no longer exists in current versions of Autoconf, which
instead unconditionally set

as_echo='printf %s\n'
as_echo_n='printf %s'



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110660] AC_LANG_INT_SAVE (used by AC_CHECK_SIZEOF) includes stdlib.h without checking whether it actually exists

[Zack Weinberg]

Follow-up Comment #1, sr #110660 (project autoconf):

You've been filing all of these bugs -- exactly which version of Autoconf are
you using to generate the configure scripts that show these bugs?  Some of the
things you have said (e.g. talking about configure.in instead of configure.ac)
suggest that you are using a *very old* version of Autoconf.

The code generated for AC_CHECK_SIZEOF, in current versions of autoconf, is
completely different from the code you quoted, and does not make any use of
either stdio.h or stdlib.h, so the bug seems moot to me.

(N.B. Current versions of autoconf do not support pre-C89 compilers.  However,
the bug report is abstractly valid anyway, because a "freestanding" C89
compiler doesn't have to provide stdio.h and stdlib.h.)


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110660] AC_LANG_INT_SAVE (used by AC_CHECK_SIZEOF) includes stdlib.h without checking whether it actually exists

[Alain Knaff]

URL:
  

 Summary: AC_LANG_INT_SAVE (used by AC_CHECK_SIZEOF) includes
stdlib.h without checking whether it actually exists
 Project: Autoconf
Submitted by: alainknaff
Submitted on: Tue 17 May 2022 08:15:00 PM CEST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

if stdlib.h doesn't exist, AC_CHECK_SIZEOF(size_t) fails with 

conftest.c:80: stdlib.h: No such file or directory
configure:5433: error: cannot compute sizeof (size_t)



Code quoted in config.log includes the following:

...
| #ifdef HAVE_UNISTD_H
| # include 
| #endif
| static long int longval () { return (long int) (sizeof (size_t)); }
| static unsigned long int ulongval () { return (long int) (sizeof (size_t));
}
| #include 
| #include 
| int
| main ()
| {
| 
|   FILE *f = fopen ("conftest.val", "w");
|   if (! f)
| return 1;
|   if (((long int) (sizeof (size_t))) < 0)
| {
|   long int i = longval ();
|   if (i != ((long int) (sizeof (size_t
|   return 1;
|   fprintf (f, "%ld", i);
| }
|   else
| {
|   unsigned long int i = ulongval ();
|   if (i != ((long int) (sizeof (size_t
|   return 1;
|   fprintf (f, "%lu", i);
| }
|   /* Do not output a trailing newline, as this causes \r\n confusion
|  on some platforms.  */
|   return ferror (f) || fclose (f) != 0;
...

As you see, most includes are correctly protected by #ifdef HAVE_*, except
stdio.h and stdlib.h

This fails if stdlib.h doesn't actually exist. Most other tests until then run
fine (AC_CHECK_LIB, AC_CHECK_HEADERS, AC_CHECK_TYPES).

N.B. I _do_ have AC_CHECK_HEADERS(stdlib.h) early in my configure.in, it
correctly determines that stdlib.h doesn't exist, but that result is not used
by AC_LANG_INT_SAVE





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110655] AT UnixPC (3b1) shell thrown off by #( after case.

[Alain Knaff]

Follow-up Comment #2, sr #110655 (project autoconf):


[comment #1 comment #1:]
> The #( is not needed by any shell I know of. It's there for two reasons: (1)
editors that match parens and get confused by 'case' with unbalanced parens.
(2) Autoconf uses that aren't properly quoted and that also get confused with
'case' with unbalanced parens.

ok, I see

> 
> (1) and (2) together suggest that we should leave the Autoconf code alone.
If you're running on a shell that doesn't do comments correctly, one fix is to
port a working shell and use that instead. You might try bootstrapping 'Bash'
by editing its configure script with 's/#((*$//' and then running 'configure;
make'. Or any other POSIX-confirming shell should do.

On further analysis, I noticed that this code is misinterpreted by the Linux
bash as well.

The only reason why this bug isn't much more apparent is that this code is
only selected in rare cases where "easier" ways (such as plain echo -n) are
not available.

The reason why this is being misinterpreted is because when expanding an
(unquoted) variable, the shell (all shells, even bash on Linux) first breaks
it into individual arguments, using white space (spaces, newlines, tabs,...)
as separators. Eval then pastes those arguments back together, but using plain
space, not what was there to begin with. Which means that the multiline
variable ends up being interpreted as a single long line. That's also the
reason why some lines (such as "arg=$1;") have a semicolon behind them:
without it, the command would merge with the following line!

One fix would be to quote the as_echo_n_body variable. However, this would
also prevent eval to be broken out as the command, so this has to go outside
the quotes, and pasted to the rest via an as_spc environment variable. So the
complete code would like the following:

as_echo_n_body='
  arg=$1;
  case $arg in #(
  *"$as_nl"*)
expr "X$arg" : "X\\(.*\\)$as_nl";
arg=`expr "X$arg" : ".*$as_nl\\(.*\\)"`;;
  esac;
  expr "X$arg" : "X\\(.*\\)" | tr -d "$as_nl"
'
export as_echo_n_body
as_spc=' '
export as_spc
as_echo_n='sh -c eval$as_spc"$as_echo_n_body" as_echo'



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Alain Knaff]

Follow-up Comment #2, sr #110657 (project autoconf):

>> For example, grep does not support -e , but egrep does.
> AC_PROG_GREP looks for a grep that does support -e, so a configure script
that uses that should have a $GREP that works, assuming you have one somewhere
in your $PATH. (If not, you'll need to get one.)

Unfortunately, my configure script does not use AC_PROG_GREP directly.

Instead, this is brought in via AC_REQUIRE by AC_PROG_EGREP, which itself is
required by AC_EGREP_CPP which is required by lots of tests for header files
etc.

However, as said in my initial report, grep is actually not used further down
in the script (AC_PROG_CPP only needs egrep, not grep). And strangely enough,
egrep *does* support the -e flag on UnixPC.

>> This lack of support of -e makes the configure script fail, although there
is a usable egrep.
> Autoconf's 'configure' script doesn't use 'grep -e' anywhere that I can
see.

And that is exactly my point. Absence of a feature which is not being used
anywhere shouldn't be a fatal error.

> Are you debugging some other 'configure' script that uses 'grep -e'?

No, I've only been debugging the mtools configure script (generated by
autoconf) as well as another configure script generated by autoconf from a
mostly empty configure.in

> If so,it should use AC_PROG_GREP

I'm not really sure how adding an explicit AC_PROG_GREP would solve the
problem brough by the implicit usage (due to AC_REQUIRE, see above)

> and "$GREP -e" and you should have a grep in your $PATH that works.

Unfortunately, this museum piece :-) doesn't have a grep where -e works, but
it *does* haven an egrep that supports -e. The issue I have is that the
configure script *doesn't* actually *need* a grep that supports -e (apart from
this test itself), and only needs egrep with -e. Neither does my own
compilation need grep -e.

(I just hope you didn't get confused by the existence of an -E (capital E)
option that makes grep behave like egrep (i.e. uses extended regexp syntax).
The -e that I am talking about here is lower case -e that makes allows to use
regular expressions that start with a dash (-), or to use multiple regular
expressions)



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110653] configure fails on AT UnixPC (3b1) due to faulty LINENO substitution

[Paul Eggert]

Update of sr #110653 (project autoconf):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Closing this as a duplicate of sr#110654.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110654] On AT UnixPC (3b1) autoconf script fails to properly replace $LINENO variable with line number

[Paul Eggert]

Update of sr #110654 (project autoconf):

  Status:None => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thanks for the bug report. Although the 3b1 is a museum piece the Autoconf
manual says other old sed implementations have a similar bug and the fix is
trivial, so I installed the attached.

(file #53209)

___

Additional Item Attachment:

File name: 0001-Work-around-AT-T-3b1-bug.patch Size:0 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

[Paul Eggert]

Update of sr #110657 (project autoconf):

Priority:  5 - Normal => 3 - Low
  Status:None => Need Info  

___

Follow-up Comment #1:

> For example, grep does not support -e , but egrep does.
AC_PROG_GREP looks for a grep that does support -e, so a configure script that
uses that should have a $GREP that works, assuming you have one somewhere in
your $PATH. (If not, you'll need to get one.)

> This lack of support of -e makes the configure script fail, although there
is a usable egrep.
Autoconf's 'configure' script doesn't use 'grep -e' anywhere that I can see.
Are you debugging some other 'configure' script that uses 'grep -e'? If so,it
should use AC_PROG_GREP and "$GREP -e" and you should have a grep in your
$PATH that works.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110655] AT UnixPC (3b1) shell thrown off by #( after case.

[Paul Eggert]

Update of sr #110655 (project autoconf):

  Status:None => Wont Do
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

The #( is not needed by any shell I know of. It's there for two reasons: (1)
editors that match parens and get confused by 'case' with unbalanced parens.
(2) Autoconf uses that aren't properly quoted and that also get confused with
'case' with unbalanced parens.

(1) and (2) together suggest that we should leave the Autoconf code alone. If
you're running on a shell that doesn't do comments correctly, one fix is to
port a working shell and use that instead. You might try bootstrapping 'Bash'
by editing its configure script with 's/#((*$//' and then running 'configure;
make'. Or any other POSIX-confirming shell should do.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110656] On AT UnixPC (3b1), parameter $3 gets overwritten (cleared) by call to subfunction.

[Paul Eggert]

Update of sr #110656 (project autoconf):

  Status:None => Wont Do
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

For this one I think we'll also suggest getting a working shell. The 3b1 is a
museum piece and it's not reasonable to expect Autoconf to make nontrivial
changes to run on a 35-year-old operating system.

> configure prints out "positional parameters were not saved." early on the
the configure process, so it seems to notice the problem, but then fails to
act on it

This is part of its attempt to find a working shell. If you provide one it
should work. If not, I expect it goes ahead anyway (and obviously fails).


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/