[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

[Bruno Haible]

Follow-up Comment #12, sr #110403 (project autoconf):

The bug exists also in the /bin/sh of Solaris OpenIndiana 20171031.

The symptom is this failure during configure:

configure: creating ./config.status
config.status: creating Makefile
gawk: ./conf0h1pqt/subs.awk:1691: cat >>"$ac_tmp/subs1.awk" <<_ACAWK &&
gawk: ./conf0h1pqt/subs.awk:1691: ^ syntax error
config.status: error: could not create Makefile


Find attached a tarball that contains
- the configure script,
- the broken config.status,
- the correct config.status (generated with CONFIG_SHELL=/usr/bin/bash).

(file #51026)
___

Additional Item Attachment:

File name: sh-bug.tar.gz  Size:363 KB




___

Reply to this item at:

  

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

Re: Version 2.72a fails with libarchive git version

[Werner LEMBERG]

Hello Zack,


thanks for the analysis.

>> [autoconf 6d38e9fa2b]
>> [clang 9.0.1]
>> [https://github.com/libarchive/libarchive.git]
>>
>> fails as below.
> ...
>> checking whether C compiler accepts -Wall... yes
>> checking whether C compiler accepts -Wformat... yes
>> checking whether C compiler accepts -Wformat-security... yes
>> checking for an ANSI C-conforming const... yes
>> checking for uid_t in sys/types.h... no
> 
> Something has already gone wrong at this point.  The corresponding bit
> of config.log reads
> 
> configure:17375: clang -c -g -O2 -Wall -Wformat -Wformat-security
> -I/usr/include/libxml2 conftest.c >&5
> configure:17375: $? = 0
> configure:17383: result: yes
> configure:17393: checking for uid_t in sys/types.h
> ./configure: line 17404: -I/usr/include/libxml2: No such file or directory
> configure:17414: result: no

It seems that

  https://github.com/libarchive/libarchive/pull/1481

fixes this: `configure.ac` misses a call to `AC_PROG_CPP`.

> The problematic check is implemented in la_uid_t.m4
> (https://github.com/libarchive/libarchive/blob/master/build/autoconf/la_uid_t.m4).
> It should be using AC_CHECK_TYPE instead of AC_EGREP_HEADER, and
> it's underquoted, but I don't see anything that would have caused
> this kind of catastrophic failure.

I guess this is another, minor issue.


Werner