I'm experimentally rebuilding rawhide with the not-yet-released GCC 15 to see if anything breaks, and to help write the porting guide. See https://fedoraproject.org/wiki/User:Dmalcolm/gcc-15 My test build with GCC 15 failed: https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-15-smoketest-3.failed/build/8476075/ whereas my test build with GCC 14 succeeded: https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-15-smoketest-3.failed.checker/build/8477655/ Looking at the failure logs e.g. https://download.copr.fedorainfracloud.org/results/dmalcolm/gcc-15-smoketest-3.failed/fedora-rawhide-x86_64/08476075-amavisd-milter/builder-live.log.gz I see: checking for sendmail install directory... default checking libmilter/mfapi.h usability... no checking libmilter/mfapi.h presence... yes checking for libmilter/mfapi.h... configure: WARNING: libmilter/mfapi.h: present but cannot be compiled configure: WARNING: libmilter/mfapi.h: check for missing prerequisite headers? configure: WARNING: libmilter/mfapi.h: see the Autoconf documentation configure: WARNING: libmilter/mfapi.h: section "Present But Cannot Be Compiled" configure: WARNING: libmilter/mfapi.h: proceeding with the compiler's result no checking for libmilter/mfapi.h... (cached) no checking for sendmail base directory in ../ ... no checking for sendmail base from /etc/mail/sendmail.cf... no checking if files required by libmilter are present... no configure: error: required milter library and header not found Perhaps due to GCC 15 now defaulting to -std=gnu23, whereas GCC 14 defaulted to -std=gnu17, and perhaps that header isn't valid C23 (but I'm guessing here) Reproducible: Always
Looking at config.log, it's a C23 issue, "bool" became a reserved word: configure:6837: gcc -c -O2 -DNDEBUG -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,- D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-harde ned-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-poin ter conftest.c >&5 In file included from conftest.c:89: /usr/include/libmilter/mfapi.h:98:17: error: two or more data types in declaration s pecifiers 98 | typedef int bool; | ^~~~ Looks like /usr/include/libmilter/mfapi.h needs fixing to support C23.
/usr/include/libmilter/mfapi.h is in the payload of the sendmail-milter-devel rpm, which is built from the sendmail src rpm; updating component and title.
Can that actually be fixed without changing the API/ABI? Looks like this will affect all milter packages. I will build mine with -std=gnu17 as a workaround, at least for now.
(In reply to Paul Howarth from comment #3) > Can that actually be fixed without changing the API/ABI? > I think this change may break ABI. Although it probably isn't critical, and just recompilation should fix it. Currently, I am not aware of any fix that is guaranteed to preserve the ABI. > Looks like this will affect all milter packages. I will build mine with > -std=gnu17 as a workaround, at least for now. > I think this is the best solution.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
FEDORA-2025-0b1123bd49 (sendmail-8.18.1-10.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-0b1123bd49
FEDORA-2025-7464ef5446 (sendmail-8.18.1-11.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-7464ef5446
FEDORA-2025-9a9d0b2762 (sendmail-8.18.1-12.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-9a9d0b2762
The upstream patch included in this update is sufficient to get sendmail itself to build in C23 mode but it does not address the subject of this ticket, namely that libmilter/mfapi.h tries to define type bool. This breaks anything that tries to include that header in C23 mode, e.g. this is with milter-regex: In file included from parse.y:42: /usr/include/libmilter/mfapi.h:98:17: error: ‘bool’ cannot be defined via ‘typedef’ 98 | typedef int bool; | ^~~~ /usr/include/libmilter/mfapi.h:98:17: note: ‘bool’ is a keyword with ‘-std=c23’ onwards make: *** [Makefile.linux:30: y.tab.o] Error 1
(In reply to Paul Howarth from comment #9) > The upstream patch included in this update is sufficient to get sendmail > itself to build in C23 mode but it does not address the subject of this > ticket, namely that libmilter/mfapi.h tries to define type bool. This breaks > anything that tries to include that header in C23 mode, e.g. this is with > milter-regex: > > In file included from parse.y:42: > /usr/include/libmilter/mfapi.h:98:17: error: ‘bool’ cannot be defined via > ‘typedef’ > 98 | typedef int bool; > | ^~~~ > /usr/include/libmilter/mfapi.h:98:17: note: ‘bool’ is a keyword with > ‘-std=c23’ onwards > make: *** [Makefile.linux:30: y.tab.o] Error 1 Hmm, there is a ifdef guard: #if SM_CONF_STDBOOL_H # include <stdbool.h> #else /* SM_CONF_STDBOOL_H */ # ifndef __cplusplus # ifndef bool # ifndef __bool_true_false_are_defined typedef int bool; # define false 0 # define true 1 # define __bool_true_false_are_defined 1 # endif /* ! __bool_true_false_are_defined */ # endif /* bool */ # endif /* ! __cplusplus */ #endif /* SM_CONF_STDBOOL_H */ So it should take stdbool.h.
(In reply to Jaroslav Škarvada from comment #10) > Hmm, there is a ifdef guard: > #if SM_CONF_STDBOOL_H > # include <stdbool.h> > #else /* SM_CONF_STDBOOL_H */ > # ifndef __cplusplus > # ifndef bool > # ifndef __bool_true_false_are_defined > typedef int bool; > # define false 0 > # define true 1 > # define __bool_true_false_are_defined 1 > # endif /* ! __bool_true_false_are_defined */ > # endif /* bool */ > # endif /* ! __cplusplus */ > #endif /* SM_CONF_STDBOOL_H */ > > So it should take stdbool.h. Indeed there is. However, this SM_CONF_STDBOOL_H symbol is defined in the private header sm/config.h and is not shipped in sendmail-milter-devel, so it's only auto-detected for the build of sendmail itself. If I add -DSM_CONF_STDBOOL_H=1 to the compilter options for my milter, it does have the desired effect, so I guess that's the way forward.
(In reply to Paul Howarth from comment #11) > (In reply to Jaroslav Škarvada from comment #10) > > Hmm, there is a ifdef guard: > > #if SM_CONF_STDBOOL_H > > # include <stdbool.h> > > #else /* SM_CONF_STDBOOL_H */ > > # ifndef __cplusplus > > # ifndef bool > > # ifndef __bool_true_false_are_defined > > typedef int bool; > > # define false 0 > > # define true 1 > > # define __bool_true_false_are_defined 1 > > # endif /* ! __bool_true_false_are_defined */ > > # endif /* bool */ > > # endif /* ! __cplusplus */ > > #endif /* SM_CONF_STDBOOL_H */ > > > > So it should take stdbool.h. > > Indeed there is. However, this SM_CONF_STDBOOL_H symbol is defined in the > private header sm/config.h and is not shipped in sendmail-milter-devel, so > it's only auto-detected for the build of sendmail itself. > > If I add -DSM_CONF_STDBOOL_H=1 to the compilter options for my milter, it > does have the desired effect, so I guess that's the way forward. I will probably bring it upstream.
Well, upstream doesn't support shared milter builds, it's fedora downstream patch, so I will probably just patch the milter headers downstream. Tips are welcome.
(In reply to Jaroslav Škarvada from comment #13) > Well, upstream doesn't support shared milter builds, it's fedora downstream > patch, so I will probably just patch the milter headers downstream. Tips are > welcome. Given that the issue is with the API in the header file, wouldn't it affect milters that were linking statically anyway?