Bug 2159284 - folks: Build in C89 mode due to Vala compiler limitations
Summary: folks: Build in C89 mode due to Vala compiler limitations
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: folks
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Florian Weimer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PortingToModernCHelpNeeded
TreeView+ depends on / blocked
 
Reported: 2023-01-09 10:15 UTC by Florian Weimer
Modified: 2024-01-19 13:12 UTC (History)
3 users (show)

Fixed In Version: folks-0.15.5-5.fc39
Clone Of:
Environment:
Last Closed: 2023-02-24 14:03:35 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME vala merge_requests 369 0 None opened codegen: Emit GCC diagnostics pragmata for GCC 14 compatibility 2024-01-19 13:12:01 UTC
Red Hat Bugzilla 2173174 0 unspecified CLOSED dino: Build in C89 mode due to Vala compiler limitations 2023-08-16 09:23:07 UTC

Internal Links: 2173174

Description Florian Weimer 2023-01-09 10:15:28 UTC
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.

Comment 1 Florian Weimer 2023-01-09 10:42:39 UTC
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>

Comment 2 Ben Cotton 2023-02-07 15:05:01 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Comment 3 Florian Weimer 2024-01-19 13:12:02 UTC
The workaround in vala-0.56.14-2.fc40 helps to paper over the remaining C type errors.


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