Misc #18726
closedCI Error on c99 and c2x
Description
https://github.com/ruby/ruby/runs/6013849896?check_suite_focus=true
checking char bit... 8
checking size of int... 0
checking size of short... 0
checking size of long... 0
configure: error: in `/__w/ruby/ruby/build':
configure: error: cannot compute sizeof (long long)
See `config.log' for more details
checking size of long long...
Error: Process completed with exit code 77.
I investigate it, the cause is that autoconf is old in ghcr.io/ruby/ruby-ci-image:clang-15
. (Autoconf 2.69)
Autoconf 2.71 generates with void
.
How to reproduce:
% docker run --rm -it ghcr.io/ruby/ruby-ci-image:clang-15
$ sudo apt update
$ sudo apt install git
$ git clone --depth=1 https://github.com/ruby/ruby $HOME/src
$ mkdir $HOME/build
$ cd $HOME/build
$ ../src/autogen.sh
$ ../src/configure -C --enable-debug-env --disable-install-doc --with-ext=-test-/cxxanyargs,+ --without-valgrind --without-jemalloc --without-gmp --with-gcc="clang-15 -std=c99 -Werror=pedantic -pedantic-errors" --enable-shared optflags=-O1 debugflags=-ggdb3
Tail of configure output:
checking char bit... 8
checking size of int... 0
checking size of short... 0
checking size of long... 0
checking size of long long... configure: error: in `/home/ci/build':
configure: error: cannot compute sizeof (long long)
See `config.log' for more details
Quote from config.log:
configure:13939: checking size of int
configure:13944: clang-15 -std=c99 -Werror=pedantic -pedantic-errors -o conftest -O1 -fno-fast-math -ggdb3 -fdeclspec -fstack-protector-strong conftest.c -lm >&5
conftest.c:107:25: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
static long int longval () { return (long int) (sizeof (int)); }
^
void
conftest.c:108:35: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
static unsigned long int ulongval () { return (long int) (sizeof (int)); }
^
void
2 errors generated.
Updated by shyouhei (Shyouhei Urabe) over 2 years ago
Is it okay to require 2.71? Or any reasons not to?
Updated by shyouhei (Shyouhei Urabe) over 2 years ago
The problem is whether we are allowed to do this.
From b60e5fdfa540a0ddef35f5dc904d004d226dac25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=8D=9C=E9=83=A8=E6=98=8C=E5=B9=B3?=
<shyouhei@ruby-lang.org>
Date: Thu, 14 Apr 2022 16:34:22 +0900
Subject: [PATCH] require autoconf 2.70
Fixes [Misc #18726]
See also https://lists.gnu.org/r/autoconf-patches/2020-08/msg00000.html
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index cbc53231d8..9f5ae83254 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,7 +3,7 @@ AC_INIT
{
AC_CONFIG_AUX_DIR(tool)
-AC_PREREQ(2.67)
+AC_PREREQ(2.70)
tooldir="$srcdir/tool"
--
2.17.1
Updated by vo.x (Vit Ondruch) over 2 years ago
shyouhei (Shyouhei Urabe) wrote in #note-1:
Is it okay to require 2.71? Or any reasons not to?
2.69 is still default on RHEL8 and similar.
Updated by alanwu (Alan Wu) over 2 years ago
Sorry, I pushed a CI fix without finding this ticket first:
https://github.com/ruby/ruby/commit/307cb57ba6d4833cc40d29d218561e98f9a1dcb9
Please feel free to amend it.
By the way, in case someone is looking at the new warnings from clang-15,
the warnings about rb_gvar_readonly_setter
are likely due to a Clang bug.
See comments: https://github.com/llvm/llvm-project/commit/11da1b53d8cd3507959022cd790d5a7ad4573d94#commitcomment-71307638
Updated by shyouhei (Shyouhei Urabe) over 2 years ago
@alanwu (Alan Wu) Thank you. I can live with that workaround. But I would also like to hear what @Eregon (Benoit Daloze) thinks. The fix ignores some C related warning, which seems somewhat against #18615.
Updated by Eregon (Benoit Daloze) over 2 years ago
Is there a way we could disable that warning only for configure checks (or even the specific configure checks which need it), i.e., therefore acknowledging it's a workaround for old autoconf and not affect the rest of the codebase?
Or the issue is it also warns for rb_define_method()
? Any way around that since that's code we control?
How to declare a var-args function with -Wstrict-prototypes
?
Newest not-even-released clang + old autoconf also sounds like a combination that is unlikely to work, I'd guess there will be other similar issues in the future.
That said I think the workaround is not too bad as it only affects the CI build for clang 15, right? And it might help with similar issues for that combination.
People building locally won't set the -Werror=pedantic -pedantic-errors
, so they will most likely not run into this.
IIRC -Wall -Werror
are mostly good/useful warnings, while some of the pedantic warnings are PITA and not worth fixing (my personal criteria being mostly: is it likely to lead to bugs or incorrect compilation or helps readability significantly?).
But that's from trying to get pedantic warnings to pass on both Linux & Solaris, which was not clearly worth the effort in my case.
Updated by Eregon (Benoit Daloze) over 2 years ago
Regarding #18615, I think it's different, we still anyway have -Werror=implicit-function-declaration
for C extensions.
And we still have all warnings for core CRuby code as long as it's not that specific matrix entry.
Also I'd think the compiler will just treat int foo() { ... }
as a var arg function, which should cause no real issue in practice (AFAIK).
Updated by alanwu (Alan Wu) over 2 years ago
Older autoconf versions and rb_define_method()
both cause warnings.
Having different flags during configure and compilation feels dangerous
to me since it makes the info from the checks potentially untrustworthy.
It feels reasonable to not try to support all of these blanket warnings-are-errors
builds because there is simply too many possible build configurations to try.
It makes sense to look at them on CI to help improve code quality, though.
We can probably devise some fix for rb_define_method()
by casting
between function pointer types, which is guaranteed to round-trip properly.
I believe internally we already cast before calling through the pointers.
Fixing things for C2X might be more challenging. It looks like WG14 is
changing int foo();
to mean int foo(void);
, and there doesn't
seem to be a replacement for the old functionality. The new warnings in Clang
are intended to help with the transition I believe. I feel that C2X with
pre-release versions of Clang is too much of a moving target. Maybe it's
best to wait a few months for things to mature. More warnings and errors
are under development and a more up-to-date standard draft should help with
understanding Clang.
Updated by shyouhei (Shyouhei Urabe) over 2 years ago
alanwu (Alan Wu) wrote in #note-8:
I feel that C2X with
pre-release versions of Clang is too much of a moving target. Maybe it's
best to wait a few months for things to mature. More warnings and errors
are under development and a more up-to-date standard draft should help with
understanding Clang.
Yes, I agree with this part. I didn't expect WG14 to become this aggressive. Clang-15 is a sooner-or-later thing, we also have to deal with C23 someday. But why not avoid mixing the two?
Updated by shyouhei (Shyouhei Urabe) over 1 year ago
- Status changed from Open to Closed
Let me close this. Clang-15 + C2X combination in our CI is stable now. If anything please reopen.