Bug 2159284
| Summary: | folks: Build in C89 mode due to Vala compiler limitations | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Florian Weimer <fweimer> |
| Component: | folks | Assignee: | Florian Weimer <fweimer> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | debarshir, gnome-sig, philip |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | folks-0.15.5-5.fc39 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-02-24 14:03:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2137512 | ||
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. |
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.