Issue with clang/llvm 16 and autoconf 2.13

[dbsoft]

So, this isn't really a big deal, but I wanted to note it and see if a discussion was necessary.

Our build system uses an absolutely ancient version of autoconf, 2.13.

As of clang/llvm 16 it breaks by default. It errors out due to the basic compiler test it tries to compile: "main() { return 0; }"

Previously -Wimplicit-int was a warning, now it is an error in C99 mode. This can be worked around by CC="/usr/bin/clang -Wno-implicit-int" but I wanted to discuss whether it is time to upgrade autoconf to a more modern version?

[vannilla]

I don't know if things have changed (probably not), but I remember seeing buried deep into some Python code a bunch of functions to parse the specific macros/output of version 2.13.
I don't know to what extent they go as I never reached the end of the tunnel, but changing Autocomf version is not as trivial as editing old-configure or something.

[Moonchild]

We require exactly autoconf-2.13 for Mozilla's build system. If it was easy enough to change we would have done that a long time ago but 2.13 processes input a specific way that later versions do not, that hard break the build system. Best we can do is silence the warning-as-error; clang devs should know better than to arbitrarily error out on specifics of an extremely mature standard like C99.

[dbsoft]

Well, not entirely onboard with the warnings becoming errors, but at the same time autoconf not declaring main as int and returning an integer is also broken.

https://www.redhat.com/en/blog/new-warn ... s-clang-16

I guess I should use the no-error thing....

CC="/usr/bin/clang -Wno-error=implicit-int"

[vannilla]

clang devs should know better than to arbitrarily error out on specifics of an extremely mature standard like C99.

In this case clang is "right" though. C99 specifies that main is to be defined with a return value compatible with int while any other definition is implementation-specific.
As such, clang has the right to reject a main function without an explicit int return value and Autoconf should've never used main functions without a return type since that's basically implementation-defined even in C89.

[dbsoft]

It seems GCC 14 also made the same change and requires the same CC option to use autoconf 2.13.

[Moonchild]

Assuming "default-int" has always been a thing if no return type was specified, and more than a few things rely on that behaviour. I don't really care whether clang is "right" according to desired declarative behaviour, here, since it's been long-standing that you can use main() without specifying its return type.

That being said: isn't this always done with an echo > conftest to test for compiler functionality? Where exactly is this being thrown?

[dbsoft]

This is the failure on Linux with GCC 14:

Code: Select all

 0:03.48 checking whether the C compiler (/usr/bin/gcc -std=gnu99  ) works... no
 0:03.48 configure: error: installation or configuration problem: C compiler cannot create executables.
 0:03.48 DEBUG: This file contains any messages produced by compilers while
 0:03.48 DEBUG: running configure, to aid debugging if configure makes a mistake.
 0:03.48 DEBUG:
 0:03.48 DEBUG: configure:888: checking host system type
 0:03.48 DEBUG: configure:909: checking target system type
 0:03.48 DEBUG: configure:927: checking build system type
 0:03.48 DEBUG: configure:1054: checking for objcopy
 0:03.48 DEBUG: configure:1918: checking for gcc
 0:03.48 DEBUG: configure:2031: checking whether the C compiler (/usr/bin/gcc -std=gnu99  ) works
 0:03.48 DEBUG: configure:2047: /usr/bin/gcc -std=gnu99 -o conftest    conftest.c  1>&5
 0:03.48 DEBUG: configure:2044:1: error: return type defaults to 'int' [-Wimplicit-int]
 0:03.48 DEBUG: configure: failed program was:
 0:03.48 DEBUG:
 0:03.48 DEBUG: #line 2042 "configure"
 0:03.48 DEBUG: #include "confdefs.h"
 0:03.48 DEBUG:
 0:03.48 DEBUG: main(){return(0);}
 0:03.48 DEBUG: configure: error: installation or configuration problem: C compiler cannot create executables.
 0:03.48 ERROR: old-configure failed
 0:03.50 *** Fix above errors and then restart with\
 0:03.50                "/usr/bin/gmake -f client.mk build"
 0:03.50 gmake: *** [client.mk:370: configure] Error 1

[athenian200]

This honestly seems like a fairly trivial problem, and it would be weird to have to go to all the trouble of upgrading autoconf just because GCC and Clang made a policy decision that affected a very small test program that isn't really essential for compiling UXP...

Is there anyway we could just not run this sanity check, or modify it so that it does have a return type without upgrading autoconf itself? It seems like talking about having to add a whole new flag or upgrade autoconf is a bit extreme.

Off-topic:
I'm getting pretty tired of the decisions made by newer versions of GCC and Clang. They keep trying to force people to explicitly add things that were assumed before. Like at one point they just decided that something wouldn't be part of the standard headers anymore and wanted everyone to explicitly add it to several files, not allowing you to decide whether to make including it the default in your project, they just decided everyone has to explicitly find every instance of that function and include that header and that users have to be okay with that. This isn't as bad as that, but I don't care for the trend.

I feel like the attitude is all about inconveniencing established projects and general users to accommodate the needs of quirkier, less popular implementations that are actually negatively impacted by historical defaults, and I'm not a fan.

But more seriously, this kind of thing is why Mozilla wanted to upgrade from autoconf and move entirely over to mozconfigure in the first place. Because autoconf changes too much from version to version... only, Python really isn't much better about API stability than autoconf is, especially not since Python 3.

[dbsoft]

We could probably force add the -Wno-error=implicit-int for Clang and GCC.

Fixing the test would require changing autoconf.

Not sure if the test can be skipped since it is a core part of the compiler tests, but maybe?

Like I said it isn't really a big deal, since we can just add a line to .mozconfig to add the compiler flag when using a new Clang or GCC... but it would be nice to have it just work.

[athenian200]

We could probably force add the -Wno-error=implicit-int for Clang and GCC.

Fixing the test would require changing autoconf.

Not sure if the test can be skipped since it is a core part of the compiler tests, but maybe?

Like I said it isn't really a big deal, since we can just add a line to .mozconfig to add the compiler flag when using a new Clang or GCC... but it would be nice to have it just work.

Right, that's what I'm asking... is there a way to just skip all the compiler tests?

I gotta say, I am not a fan of the fact that the test is internal to autoconf in such a way that we're expected to upgrade the entire tool and rework every part of our build system that relies on autoconf because a one-line automated test broke due to a newer compiler being slightly more pedantic about default int. Fixing conftest.c would be a one-line change I could make as root on any system where it's installed... the problem is that that patch would be needed for every single system UXP is built on, because it doesn't look in our code for the test, and relies on something internal to autoconf with no obvious way to override it other than taking on board all the new stuff in newer autoconf versions that breaks things for us.

I'm actually kind of worried we may have to fork autoconf in the future to keep it working on newer compilers if this keeps up, though. That's how big a deal it would be to use a newer version... we would be forced to fork the existing one and maintain it ourselves as compiler changes break it. We and Mozilla have been lucky enough to be able to use autoconf 2.13 as-is for a long time now, but I'm worried our luck may be running out... and we don't really have an alternative that doesn't involve forking autoconf to make it work on newer GCC and Clang if it breaks.

I know we can work around this for now, but I have to admit I am borrowing trouble a bit here... and it makes me nervous about our entire build infrastructure and how hard it is getting to compile our stuff on a modern Linux distro, and how we just don't have the resources to keep up with maintaining such a large build system on top of the thing it builds.

Ultimately, I have to divide the blame here between the Autoconf authors who wrote conftest.c decades ago, and the compiler authors who decided to kill default int. Using default int was never clean code or good practice, it would have taken them two extra seconds back then... but still, given that so much code exists that was written this way, including something we've inherited that we don't have much control over, it's frustrating that the compiler developers are just apathetic about how much work they are putting on everyone with these kind of decisions. Why make this change now? Sure, using default int was one of those little things most people knew they weren't really supposed to do, but because compilers accommodated it, a lot of people never changed their bad habits, and they've gone from respecting the developers time to "We've tolerated this long enough, now you all have to fix your stuff just because it's 2024. Tough if you don't like it." I don't feel that we bear any real fault here, and are basically being impacted by slightly sloppy coding in autoconf 2.13 and pedantic modern compilers colliding in a bad way.

Basically, because that guy 10 years ago or so didn't take two extra seconds to type "int main" instead of just "main," we're narrowly avoiding having to spend resources forking autoconf or reworking our build system to use a newer one... that option to allow implicit int might not exist at all in the next version of Clang or GCC. Don't you just love programming? So glad I didn't make this my day job...

[dbsoft]

Basically, because that guy 10 years ago or so didn't take two extra seconds to type "int main" instead of just "main"

25+ years ago! autoconf 2.13 was released in 1999 and that test is probably older than that!

Edit: Just out of curiosity I found the autoconf repository and found when that code was added... 28 years ago - Nov 19, 1996:

https://github.com/autotools-mirror/aut ... 936be75eb9

[Moonchild]

I'm still not sure which AC line in which file exactly triggers this. The debug output seems to indicate conftest.c is being compiled as part of "configure" (which isn't our main configure since that would be old-configure) but all occurrences of that in the tree are created with an echo command that includes the implicit "int"...?

We should be able to just replace whatever the issue is here with that kind of construct like we have been doing just about everywhere. i definitely don't see a need to fork autoconf for this. Just find the failing check and make it compatible.

[dbsoft]

https://repo.palemoon.org/MoonchildProd ... re.in#L114

Pretty sure it is this line which detects the compiler and checks to see it works...

AC_PROG_CC is in acspecific.m4 which calls AC_PROG_CC_WORKS which is also in there with the following test:

AC_TRY_COMPILER([main(){return(0);}], ac_cv_prog_cc_works, ac_cv_prog_cc_cross)

acspecifc.m4 is part of autoconf in case that wasn't clear, this is the basic compiler test in autoconf.

[Moonchild]

So how about we do the following instead:

Code: Select all

AC_TRY_COMPILER([int main(){return(0);}], ac_cv_prog_cc_works, ac_cv_prog_cc_cross)

[dbsoft]

So how about we do the following instead:

Code: Select all

AC_TRY_COMPILER([int main(){return(0);}], ac_cv_prog_cc_works, ac_cv_prog_cc_cross)

That is what needs to be done, but that code is in AC_PROG_CC_WORKS within autoconf.

[Moonchild]

That is what needs to be done, but that code is in AC_PROG_CC_WORKS within autoconf.

ohh ok now i get it. so... autoconf is written using autoconf macros? Talk about circular.

Can't we just redefine AC_PROG_CC to be an acceptable format outside of autoconf itself?

[dbsoft]

Can't we just redefine AC_PROG_CC to be an acceptable format outside of autoconf itself?

Maybe we can redefine AC_PROG_CC_WORKS in aclocal.. but I've never tried to redefine internal autoconf stuff before... not sure if it is possible or how it works.

[Moonchild]

Well we already have a whole bunch of autoconf hacks going on in the tree in /build/autoconf -- probably a good location would be inside /build/autoconf/hotfixes.m4 -- looks like macros can just be defined there. But I don't know if that would override anything internal...

[vannilla]

Can you define a new macro, UXP_PROG_CC or something, that is implemented like the macro from Autoconf 2.13 but doesn't use the old main definition and substitute in in old-configure?
Untested, but maybe this:

Code: Select all

AC_DEFUN(UXP_PROG_CC,
[AC_BEFORE([$0], [AC_PROG_CPP])dnl
AC_CHECK_PROG(CC, gcc, gcc)
if test -z "$CC"; then
  AC_CHECK_PROG(CC, cc, cc, , , /usr/ucb/cc)
  test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH])
fi

AC_MSG_CHECKING([whether the C compiler ($CC $CFLAGS $LDFLAGS) works])
AC_LANG_SAVE
AC_LANG_C
AC_TRY_COMPILER([int main(){return(0);}], ac_cv_prog_cc_works, ac_cv_prog_cc_cross)
AC_LANG_RESTORE
AC_MSG_RESULT($ac_cv_prog_cc_works)
if test $ac_cv_prog_cc_works = no; then
  AC_MSG_ERROR([installation or configuration problem: C compiler cannot create executables.])
fi
AC_MSG_CHECKING([whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler])
AC_MSG_RESULT($ac_cv_prog_cc_cross)
cross_compiling=$ac_cv_prog_cc_cross

AC_PROG_CC_GNU

if test $ac_cv_prog_gcc = yes; then
  GCC=yes
dnl Check whether -g works, even if CFLAGS is set, in case the package
dnl plays around with CFLAGS (such as to build both debugging and
dnl normal versions of a library), tasteless as that idea is.
  ac_test_CFLAGS="${CFLAGS+set}"
  ac_save_CFLAGS="$CFLAGS"
  CFLAGS=
  AC_PROG_CC_G
  if test "$ac_test_CFLAGS" = set; then
    CFLAGS="$ac_save_CFLAGS"
  elif test $ac_cv_prog_cc_g = yes; then
    CFLAGS="-g -O2"
  else
    CFLAGS="-O2"
  fi
else
  GCC=
  test "${CFLAGS+set}" = set || CFLAGS="-g"
fi
])