Re: Possible regressions with trunk autoconf (vs 2.71)

2022-11-17 Thread Frederic Berat
Thanks, I'll update the bug I opened for them. On Thu, Nov 17, 2022 at 6:54 PM Zack Weinberg wrote: > On 2022-11-17 9:30 AM, Zack Weinberg wrote: > > Or even better, get rid of the AC_EGREP_CPP at the same time > > > > AC_CACHE_CHECK([whether we need to define $1], ac_var, > >

Re: Possible regressions with trunk autoconf (vs 2.71)

2022-11-17 Thread Frederic Berat
Yes and yes. On Thu, Nov 17, 2022 at 7:16 PM Paul Eggert wrote: > On 2022-11-17 04:41, Frederic Berat wrote: > > They have the following code in their aclocal.m4{,.cross} files: > > Does the attached, self-contained configure.ac illustrate the problem > for you? I don't want to have to figure

Re: How can Autoconf help with the transition to stricter compilation defaults?

2022-11-17 Thread Paul Eggert
On 11/17/22 13:35, Bruno Haible wrote: Clang will surely not acquire knowledge about "every library", right, only about the C library according to relevant standards (ISO C, POSIX)? I don't know the Clang developers' plans. But if I wanted Clang to be picky then yes, I'd have it know about

Re: How can Autoconf help with the transition to stricter compilation defaults?

2022-11-17 Thread Bruno Haible
Paul Eggert wrote: > > AC_CHECK_FUNC *should not* just probe for linkability of a symbol > > ... Autoconf cannot > be expected to know every signature of every function in every library. Clang will surely not acquire knowledge about "every library", right, only about the C library according to

Re: How can Autoconf help with the transition to stricter compilation defaults?

2022-11-17 Thread Paul Eggert
On 2022-11-16 10:59, Zack Weinberg wrote: I'm generally in agreement with Rich Felker's argument (inhttps://ewontfix.com/13/) that AC_CHECK_FUNC*should not* just probe for linkability of a symbol So am I. I'm not saying Autoconf should never change here, only that the change would not be

Re: How can Autoconf help with the transition to stricter compilation defaults?

2022-11-17 Thread Paul Eggert
On 2022-11-16 10:40, Jeffrey Walton wrote: This line of arguments is not persuasive. It is full of logical fallacies. ... none of which you stated. No matter how we solve the problem, it will be a hack that exploits "logical fallacies" (whatever that means). However, a reaction "You

Re: Possible regressions with trunk autoconf (vs 2.71)

2022-11-17 Thread Paul Eggert
On 2022-11-17 04:41, Frederic Berat wrote: They have the following code in their aclocal.m4{,.cross} files: Does the attached, self-contained configure.ac illustrate the problem for you? I don't want to have to figure out all of Wine. Also, can you narrow down which Autoconf commit causes

Re: Possible regressions with trunk autoconf (vs 2.71)

2022-11-17 Thread Zack Weinberg
On 2022-11-17 9:30 AM, Zack Weinberg wrote: Or even better, get rid of the AC_EGREP_CPP at the same time AC_CACHE_CHECK([whether we need to define $1], ac_var, [AC_PREPROC_IFELSE([[#ifndef $1 #error not defined #endif]], [AS_VAR_SET(ac_var,yes)],[AS_VAR_SET(ac_var,no)])])

Re: Possible regressions with trunk autoconf (vs 2.71)

2022-11-17 Thread Zack Weinberg
On Thu, Nov 17, 2022, at 7:41 AM, Frederic Berat wrote: > One more failure analysis, this time for Wine. > They have the following code in their aclocal.m4{,.cross} files: ... > dnl Check whether we need to define a symbol on the compiler command > line > dnl > dnl Usage:

Re: Possible regressions with trunk autoconf (vs 2.71)

2022-11-17 Thread Frederic Berat
Hello again, One more failure analysis, this time for Wine. They have the following code in their aclocal.m4{,.cross} files: dnl Check whether we need to define a symbol on the compiler command line dnl dnl Usage: WINE_CHECK_DEFINE(name),[action-if-yes,[action-if-no]]) dnl