Bug 2336029 - abook fails to build with GCC 15 ("mbswidth.c:66:5: error: conflicting types for ‘wcwidth’; have ‘int(void)’")
Summary: abook fails to build with GCC 15 ("mbswidth.c:66:5: error: conflicting types ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: abook
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Dominik 'Rathann' Mierzejewski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: gcc-15-mass-prebuild
TreeView+ depends on / blocked
 
Reported: 2025-01-06 22:41 UTC by Dave Malcolm
Modified: 2025-01-09 12:58 UTC (History)
2 users (show)

Fixed In Version: abook-0.6.1-28.fc42
Clone Of:
Environment:
Last Closed: 2025-01-09 12:58:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dave Malcolm 2025-01-06 22:41:46 UTC
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/8476061/

whereas my test build with GCC 14 succeeded:
https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-15-smoketest-3.failed.checker/build/8477620/

Looking at the failure logs e.g.
https://download.copr.fedorainfracloud.org/results/dmalcolm/gcc-15-smoketest-3.failed/fedora-rawhide-x86_64/08476061-abook/builder-live.log.gz

I see:

mbswidth.c:66:5: error: conflicting types for ‘wcwidth’; have ‘int(void)’
   66 | int wcwidth ();
      |     ^~~~~~~
In file included from mbswidth.c:42:
/usr/include/wchar.h:392:12: note: previous declaration of ‘wcwidth’ with type ‘int(wchar_t)’ {aka ‘int(int)’}
  392 | extern int wcwidth (wchar_t __c) __THROW;
      |            ^~~~~~~
mbswidth.c: In function ‘mbsnwidth’:
mbswidth.c:185:25: error: too many arguments to function ‘wcwidth’
  185 |                     w = wcwidth (wc);
      |                         ^~~~~~~
mbswidth.c:66:5: note: declared here
   66 | int wcwidth ();
      |     ^~~~~~~
mbswidth.c: In function ‘mbsnbytes’:
mbswidth.c:303:25: error: too many arguments to function ‘wcwidth’
  303 |                     w = wcwidth (wc);
      |                         ^~~~~~~
mbswidth.c:66:5: note: declared here
   66 | int wcwidth ();
      |     ^~~~~~~



This is probably due to GCC 15 now defaulting to -std=gnu23, whereas GCC 14 defaulted to -std=gnu17, and C23 is stricter about function prototypes than C17.  It's probably fixable by fixing the function prototypes (or by manually adding -std=gnu17 to the C build flags)


Reproducible: Always

Comment 1 Dominik 'Rathann' Mierzejewski 2025-01-09 12:01:47 UTC
The issue was that configure check was failing to detect wcwidth() declaration due to missing #include <wchar.h>:

...
checking whether wcwidth is declared... no
...

which resulted in the wrong wcwidth prototype

After patching configure.ac with:
diff -up abook-0.6.1/configure.ac.orig abook-0.6.1/configure.ac
--- abook-0.6.1/configure.ac.orig       2015-10-04 04:37:39.000000000 +0200
+++ abook-0.6.1/configure.ac    2025-01-09 12:32:06.449796137 +0100
@@ -61,7 +61,7 @@ AC_CHECK_HEADER(wchar.h,[
        AC_DEFINE(HAVE_WCHAR_H, 1, [Define if you have the <wchar.h> header file.])],
        [ac_have_wchar_h=no])
 AC_CHECK_FUNCS(mbtowc wcwidth mbrtowc mbsinit,,ac_widec_funcs=no)
-AC_CHECK_DECLS(wcwidth)
+AC_CHECK_DECLS([wcwidth], [], [], [[#include <wchar.h>]])
 AC_CHECK_TYPE(wchar_t,,ac_widec_funcs=no)
 
 if test x$ac_widec_funcs = xyes -a x$ac_have_wchar_h = xyes; then

wcwidth declaration is detected and build with -std=gnu23 succeeeds.

Comment 2 Fedora Update System 2025-01-09 12:13:05 UTC
FEDORA-2025-1bc6fd32b9 (abook-0.6.1-28.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-1bc6fd32b9

Comment 3 Fedora Update System 2025-01-09 12:58:57 UTC
FEDORA-2025-1bc6fd32b9 (abook-0.6.1-28.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.