Too many errors to list, in addition to an abundance of other warnings with clang. Ancient codebase with super dodgy C code. I tried & managed to fix some problems caused by -Werror=strict-prototypes, but a few callbacks are defined as function pointers with an undefined & arbitrary number of arguments, and various call sites then do just that. Reproducible: Always
In such cases, please include the build.log & emerge --info for completeness.
Build log is huge (due to too many warnings) but I managed to capture the first relevant build error: clang -DHAVE_CONFIG_H -I../../include -I../../include -I/usr/include/openssl -g -pipe -march=native -O2 -Werror=strict-prototypes -c -o canaccess.o canaccess.c In file included from canaccess.c:18: In file included from ./../charconv/utf8.h:24: ./../charconv/../filttype.h:56:24: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] typedef int (*gf_io_t)(); /* type of get and put char function */ ^ void 1 error generated.
I just spent the better part of my Sunday morning trying to get a handle on the amount of work required to fix this. Unfortunately it's a bottomless pit of fractal weirdness. Without a massive rewrite by upstream this will never be clean due to _intentional_ casts, prototype violations and other portability hacks (to appease DOS, Windows, OSF/1, Sequent and other popular platforms). The biggest holdup - which is not easily fixed - is that a single function pointer (gf_io_t) without arguments is being used for both getchar() and putchar() invocations, and it's so pervasive that it cannot be fixed incrementally. Not even the configure script can be easily fixed since it intentionally uses incorrect prototypes to detect curses functions. Our best bet for now is to explicitly configure with -Wno-error=strict-prototypes, so that when gcc & clang enable strictness by default it will at least configure correctly and compile.
iirc soap spent ages on this as well and didn't get far
(In reply to Sam James from comment #4) > iirc soap spent ages on this as well and didn't get far Good to know :/ I'll see if I can fix up the ebuild to work when clang is armed with -Wstrict-prototypes via config. Maybe also use the external c-client IMAP lib instead of the bundled one, but so far I have not even been able to figure out which version is bundled. More as it happens..
I'd start with adding -std=gnu89 or so to the ebuild then work on any other errors. Strict prototypes are at least issues we can safely ignore if we can set an older standard. Implicit func decls, implicit int, incompat. func. ptr. types are real problems however. (Note that if setting 89, need explicit -W for implicit warnings)
In case anybody wants to play along, my changes going upstream can be found in my branch at: https://github.com/hhoffstaette/alpine/tree/strict-prototypes
Fwiw using -std=gnu89 made things worse by un-defining various XOPEN_SOURCE defines, from where it went downhill even further.
(In reply to Holger Hoffstätte from comment #8) > Fwiw using -std=gnu89 made things worse by un-defining various XOPEN_SOURCE > defines, from where it went downhill even further. what about c89?
(In reply to Sam James from comment #9) > (In reply to Holger Hoffstätte from comment #8) > > Fwiw using -std=gnu89 made things worse by un-defining various XOPEN_SOURCE > > defines, from where it went downhill even further. > > what about c89? I didn't try but it was also not really necessary - the C standard compliance is not the problem and trying to coax it backwards is probably harder than just fixing things moving forward.
I was writing on mobile for these comments and didn't explain very clearly. strict-prototypes only really matters if one day it's going to build with C23. Alpine is an ancient codebase and I don't think that's really going to happen any time soon. You can suppress those warnings by setting -std=c89 or -std=gnu89 or whatever depending on what it was genuinely written for, so we can focus on warnings which actually matter wrt runtime like implicit. func decls or dodgy casts. In general, we shouldn't waste time on strict-prototypes bugs for now until all the C99 stuff is sorted (implicit. func. decls, implicit int, incompatible. func. ptr. types). Of course, if someone wants to, they should feel free, I just mean it's not the same level of importance right now.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=22328c31f2d45f383a11ffe7c68b7cc77350c8a4 commit 22328c31f2d45f383a11ffe7c68b7cc77350c8a4 Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2023-08-27 16:27:56 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-08-29 06:06:03 +0000 mail-client/alpine: workarounds for strict prototypes & make --shuffle The alpine build is quite fragile and not easily fixed. For now we need to disable make's --shuffle used on the Tinderbox, and disable failing to build at all when -Werror=strict-prototypes is enabled. Closes: https://bugs.gentoo.org/888709 Closes: https://bugs.gentoo.org/870766 Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Closes: https://github.com/gentoo/gentoo/pull/32477 Signed-off-by: Sam James <sam@gentoo.org> mail-client/alpine/alpine-2.26-r3.ebuild | 101 +++++++++++++++++++++++++++++++ 1 file changed, 101 insertions(+)
