[sr #110367] AC_FUNC_STRERROR_R regression on autoconf-2.69d compared to 2.69

[Sergei Trofimovich]

URL:
  <https://savannah.gnu.org/support/?110367>

                 Summary: AC_FUNC_STRERROR_R regression on autoconf-2.69d
compared to 2.69
                 Project: Autoconf
            Submitted by: slyfox
            Submitted on: Вс 08 ноя 2020 12:21:29
                Category: None
                Priority: 5 - Normal
                Severity: 4 - Important
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

Initially the bug is observed on thin-provisioning-tools-0.9.0 package where
build started failing due to mis-detection of `strerror_r` prototype.

Probably related to C++. Minimal configure snippet that detects different
prototypes:

$ cat configure.ac
AC_PREREQ(2.61)
AC_INIT
AC_PROG_CXX([g++])
AC_PROG_CC([gcc])
AC_LANG(C++)

AC_FUNC_STRERROR_R

AC_OUTPUT

$ autoconf-2.69 && ./configure --host=x86_64-pc-linux-gnu
checking for x86_64-pc-linux-gnu-g++... x86_64-pc-linux-gnu-g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether x86_64-pc-linux-gnu-g++ accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed
checking how to run the C++ preprocessor... x86_64-pc-linux-gnu-g++ -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether strerror_r is declared... yes
checking for strerror_r... yes
checking whether strerror_r returns char *... yes
configure: creating ./config.status

$ autoconf-2.70_beta3 && ./configure --host=x86_64-pc-linux-gnu
checking for x86_64-pc-linux-gnu-g++... x86_64-pc-linux-gnu-g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C++... yes
checking whether x86_64-pc-linux-gnu-g++ accepts -g... yes
checking for x86_64-pc-linux-gnu-g++ option to enable C++11 features... none
needed
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the compiler supports GNU C... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to enable C11 features... none
needed
checking how x86_64-pc-linux-gnu-g++ reports undeclared, standard C
functions... error
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether strerror_r is declared... yes
checking whether strerror_r returns char *... no
configure: creating ./config.status

Note, the final problem here is the difference in:

checking whether strerror_r returns char *... yes
checking whether strerror_r returns char *... no

In progobal project it get used in
https://github.com/jthornber/thin-provisioning-tools/blob/main/configure.ac#L63
and fails to build later.

Should AC_FUNC_STRERROR_R pull in more headers (or defines?) explicitly?




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/support/?110367>

_______________________________________________
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/