Re: Request to revert the C version change
On Wed, 16 Dec 2020 17:04:31 +, Ross Burton wrote: > All through the 2.70 prelease cycle I was periodically running builds > of OpenEmbedded with the snapshots as they were released. As we > autoreconf by default this was great at shaking out some bugs in both > packages and autoconf itself. However, I see that in between the > Release Candidate and the final release a large breaking change to C > version detection was integrated that basically means that any > software using gnulib needs to update? Perhaps you are hitting this bug that breaks C99 flag detection? https://savannah.gnu.org/support/?110396 - todd
Re: Request to revert the C version change
On Wed, 16 Dec 2020 14:48:19 -0600, Bob Friesenhahn wrote: > On Wed, 16 Dec 2020, Todd C. Miller wrote: > > > > Perhaps you are hitting this bug that breaks C99 flag detection? > >https://savannah.gnu.org/support/?110396 > > What are the impacts of that? The impact is that the configure script will incorrectly decide that no compiler flag is needed to support C99 features. It should only be a problem on older compilers that don't support C99 by default. In my case, I noticed it with gcc version 4.2.1 (gccfss). > I just opened this new one. Is it related? > > sr #110403: autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS > > https://savannah.gnu.org/support/index.php?110403 That looks to be a different issue. The version of gcc you are using supports C11 features without requiring any flags. > This test used to work fine on the same system, which has not been > changed throughout the release cycle. I must admit that I did not > test the last release candidate before formal release, but I did test > the other ones. I'm not sure why that test is failing when the unsigned version does not. From the log it certainly appears that intmax_t is discovered correctly. I wonder if this is related: ./config.status: line 556: syntax error at line 562: `<<' unmatched - todd
Re: AC_PROG_CC: how to distinguish clnag from gcc?
On Fri, 05 Feb 2021 15:42:28 +0100, =?utf-8?Q?S=C3=A9bastien?= Hinderer wrote: > It seems AC_PROG_CC wrongly believes clang is gcc and that may cause problems > when clang is passed a warning which is only supposrted by gcc, as is > the case e.g. for -Wno-stringop-truncation. clang also defines __GNUC__ and the related defines, which is why it is identified as gcc. > Is there a recommended way to determine for sure from a configure script > whether the detected C compiler is clang or gcc? You need to test whether the specific warning flag is supported by the compiler. These flags also vary based on gcc version so this is not a problem specific to clang. I like to use AX_CHECK_COMPILE_FLAG for this, see: http://www.gnu.org/software/autoconf-archive/ax_check_compile_flag.html - todd
Re: config.sub/config.guess using nonportable $(...) substitutions
On Tue, 09 Mar 2021 14:11:36 -0700, Warren Young wrote: > That’s the real trick, isn’t it? We have to set *some* threshold for droppin > g support for old platforms. I expect Autoconf isn’t compatible with Ultrix > any more, for instance. That's a good reminder that we've been here before. I remember being somewhat irked when autoconf stopped working with the SunOS 4.x /bin/sh (due to the use of shell functions IIRC). When I found that bash would process the script far faster than the V7-derived shell could I didn't mind any more :-) And as Paul pointed out earlier, Solaris 10 has multiple shells that support $( cmd ) syntax, they just aren't called /bin/sh. - todd
Re: AC_PROG_LEX issue when compiling with -Werror
On Thu, 14 Jul 2022 12:03:42 +0200, Tobias Brunner wrote: > This is caused by the following warnings turned errors from the > generated lexer: > > lex.yy.c:673:13: error: misleading indentation; statement is not part of > the previous 'if' [-Werror,-Wmisleading-indentation] > if ( ! (yy_state_buf) ) > ^ > lex.yy.c:671:9: note: previous statement is here > if ( ! (yy_state_buf) ) > ^ > lex.yy.c:1107:3: error: misleading indentation; statement is not part of > the previous 'if' [-Werror,-Wmisleading-indentation] > return yy_is_jam ? 0 : yy_current_state; > ^ > lex.yy.c:1104:2: note: previous statement is here > if ( ! yy_is_jam ) > ^ > > Note that these warnings are not triggered for our own lexers, > presumably because we don't use REJECT, which seems to generate the > above code. That is, building with -Werror works just fine if the > library check is bypassed. Why not just fix your flex.skl so it doesn't produce code that generates a warning? We fixed this problem in OpenBSD so you can probably just adapt the indentation changes from: https://github.com/openbsd/src/commit/1e0c6b38375efb02b888b583b475861337640240 https://github.com/openbsd/src/commit/f185ba58eb4e17172f33aba354b7b635e52cea2c The test program does not generate warnings with clang 13 on OpenBSD. - todd
Re: AC_PROG_LEX issue when compiling with -Werror
Sorry, I missed the fact that you are trying to build on FreeBSD, not develop FreeBSD itself. Still, I'd suggest filing a bug with FreeBSD to fix their flex.skl. - todd
AC_CHECK_HEADER_STDBOOL regression with trunk autoconf
Commit 6dcecb780a69bd208088d666b299e92aa7ae7e80 "Port AC_CHECK_HEADER_STDBOOL to C23" causes AC_CHECK_HEADER_STDBOOL to fail even on systems with a conforming stdbool.h. There is no longer an 'a' variable so it should not be referenced in the return statement. - todd diff --git a/lib/autoconf/headers.m4 b/lib/autoconf/headers.m4 index 5fde7f5a..43f55ed2 100644 --- a/lib/autoconf/headers.m4 +++ b/lib/autoconf/headers.m4 @@ -639,7 +639,7 @@ AC_DEFUN([AC_CHECK_HEADER_STDBOOL], /* Refer to every declared value, so they cannot be discarded as unused. */ - return (!a + !b + !c + !d + !e + !f + !g + !h + !i + !j + !k + return (!b + !c + !d + !e + !f + !g + !h + !i + !j + !k + !l + !m + !n + !o + !p + !pp + !ps); ]])], [ac_cv_header_stdbool_h=yes],
[PATCH] fix AC_CHECK_HEADER_STDBOOL regression
[Resending since this appears to have gotten lost]. Commit 6dcecb780a69bd208088d666b299e92aa7ae7e80 "Port AC_CHECK_HEADER_STDBOOL to C23" causes AC_CHECK_HEADER_STDBOOL to always fail, even on systems with a conforming stdbool.h. There is no longer an 'a' variable so it should not be referenced in the return statement. - todd diff --git a/lib/autoconf/headers.m4 b/lib/autoconf/headers.m4 index c5acd16e..ccb1bf4b 100644 --- a/lib/autoconf/headers.m4 +++ b/lib/autoconf/headers.m4 @@ -639,7 +639,7 @@ AC_DEFUN([AC_CHECK_HEADER_STDBOOL], /* Refer to every declared value, so they cannot be discarded as unused. */ - return (!a + !b + !c + !d + !e + !f + !g + !h + !i + !j + !k + return (!b + !c + !d + !e + !f + !g + !h + !i + !j + !k + !l + !m + !n + !o + !p + !pp + !ps); ]])], [ac_cv_header_stdbool_h=yes],
