folks/redeclare-internal-api.h contains this: /* These functions are marked 'internal', which means Vala makes them ABI * but omits them from header files. * * We can't just tell valac to generate an "internal" VAPI and header * via -h and --internal-vapi, because the "internal" header redefines * things like "typedef struct _FolksPersonaStore FolksPersonaStore" * which are an error if redefined; so you can only include the "internal" * header or the "public" one, never both. If we use the "internal" * VAPI then libfolks-eds' "public" header ends up trying to include * the "internal" header of libfolks, which is unacceptable. * * Redundant declarations of functions and macros, unlike typedefs, are * allowed by C as long as they have identical content. We ought to be able * to check that these declarations match what Vala is currently generating * by including this header when compiling libfolks. Unfortunately, * if we do that we can't include <folks/folks.h>, because Vala-generated * C code redeclares local Vala-generated types, functions, etc. rather than * just including <folks/folks.h>, and then the typedefs conflict. */ void folks_persona_store_set_is_user_set_default (FolksPersonaStore* self, gboolean value); This leads to a build failure in dummy-persona-store.vala: gcc -Ibackends/dummy/lib/libfolks-dummy.so.26.0.0.p -Ibackends/dummy/lib -I../backends/dummy/lib -Ifolks -I../folks -I. -I.. -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gee-0.8 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -w -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC -pthread -include config.h '-DBACKEND_NAME="dummy"' '-DG_LOG_DOMAIN="dummy"' -MD -MQ backends/dummy/lib/libfolks-dummy.so.26.0.0.p/meson-generated_dummy-persona-store.c.o -MF backends/dummy/lib/libfolks-dummy.so.26.0.0.p/meson-generated_dummy-persona-store.c.o.d -o backends/dummy/lib/libfolks-dummy.so.26.0.0.p/meson-generated_dummy-persona-store.c.o -c backends/dummy/lib/libfolks-dummy.so.26.0.0.p/dummy-persona-store.c ../backends/dummy/lib/dummy-persona-store.vala: In function ‘folks_dummy_persona_store_update_is_user_set_default’: ../backends/dummy/lib/dummy-persona-store.vala:998:2: error: implicit declaration of function ‘folks_persona_store_set_is_user_set_default’ 998 | this.is_user_set_default = is_user_set_default; | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'm no sure if this is a generic Vala compiler issue.
I've raised this on the Gnome forum as well: C99 compatibility of internal setters <https://discourse.gnome.org/t/c99-compatibility-of-internal-setters/13360>
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
The workaround in vala-0.56.14-2.fc40 helps to paper over the remaining C type errors.