Bug 2340915 - neovim: FTBFS in Fedora rawhide/f42
Summary: neovim: FTBFS in Fedora rawhide/f42
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: neovim
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Andreas Schneider
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F42FTBFS
TreeView+ depends on / blocked
 
Reported: 2025-01-22 21:05 UTC by Fedora Release Engineering
Modified: 2025-01-23 12:46 UTC (History)
16 users (show)

Fixed In Version: neovim-0.10.3-5.fc42
Clone Of:
Environment:
Last Closed: 2025-01-23 12:46:25 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
build.log (32.00 KB, text/plain)
2025-01-22 21:05 UTC, Fedora Release Engineering
no flags Details
root.log (32.00 KB, text/plain)
2025-01-22 21:05 UTC, Fedora Release Engineering
no flags Details
state.log (1.63 KB, text/plain)
2025-01-22 21:05 UTC, Fedora Release Engineering
no flags Details

Description Fedora Release Engineering 2025-01-22 21:05:05 UTC
neovim failed to build from source in Fedora rawhide/f42

https://koji.fedoraproject.org/koji/taskinfo?taskID=128019567


For details on the mass rebuild see:

https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild
Please fix neovim at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
neovim will be orphaned. Before branching of Fedora 43,
neovim will be retired, if it still fails to build.

For more details on the FTBFS policy, please visit:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

Comment 1 Fedora Release Engineering 2025-01-22 21:05:09 UTC
Created attachment 2071276 [details]
build.log

file build.log too big, will only attach last 32768 bytes

Comment 2 Fedora Release Engineering 2025-01-22 21:05:11 UTC
Created attachment 2071277 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Comment 3 Fedora Release Engineering 2025-01-22 21:05:12 UTC
Created attachment 2071278 [details]
state.log

Comment 4 Andreas Schneider 2025-01-23 09:22:08 UTC
I think this is actually a GCC bug:

/builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/src/nvim/api/buffer.c: In function ‘nvim_buf_get_lines’:
/builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/src/nvim/api/buffer.c:272:45: error: passing argument 4 of ‘normalize_index’ from incompatible pointer type [-Wincompatible-pointer-types]
  272 |   start = normalize_index(buf, start, true, &oob);
      |                                             ^~~~
      |                                             |
      |                                             _Bool *
In file included from /builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/src/nvim/api/private/helpers.h:186,
                 from /builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/src/nvim/api/buffer.c:16:
/builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/redhat-linux-build/include/api/private/helpers.h.generated.h:31:96: note: expected ‘unsigned int *’ but argument is of type ‘_Bool *’
   31 | DLLEXPORT int64_t normalize_index(buf_T *buf, int64_t index, unsigned end_exclusive, unsigned *oob);
      |                                                                                      ~~~~~~~~~~^~~


The helpers.h.generated.h is generated using a lua script:

/usr/bin/luajit /builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/src/nvim/generators/preload.lua /builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3 /builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/redhat-linux-build/lib/libnlua0.so /builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/redhat-linux-build /builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/src/nvim/generators/gen_declarations.lua /builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/src/nvim/api/private/helpers.c /builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/redhat-linux-build/src/nvim/auto/api/private/helpers.c.generated.h /builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/redhat-linux-build/include/api/private/helpers.h.generated.h /builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/redhat-linux-build/src/nvim/auto/api/private/helpers.i

As input it uses /builddir/build/BUILD/neovim-0.10.3-build/neovim-0.10.3/redhat-linux-build/src/nvim/auto/api/private/helpers.i which is the preprocessed helpers.c file!


<mock-chroot> sh-5.2# grep normalize helpers.i                                                                                                                                            
int64_t normalize_index(buf_T *buf, int64_t index, _Bool end_exclusive, _Bool *oob)



This means that the preprocessor replaces bool with _Bool!

Comment 5 Andreas Schneider 2025-01-23 09:26:44 UTC
Could be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117633

Comment 6 Jakub Jelinek 2025-01-23 09:31:50 UTC
That is not a gcc bug.
_Bool is a boolean type distinct from normal integral types (already starting with C99).
When stdbool.h header is included (except for C23), bool is a macro defined to _Bool:
#if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L
/* bool, true and false are keywords.  */
#else
#define bool    _Bool
#define true    1
#define false   0
#endif
Passing pointer to _Bool (or the C23 bool, those 2 are the same thing) to a function which expects unsigned * argument is invalid.

Comment 7 Jakub Jelinek 2025-01-23 09:35:46 UTC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117633 is about an internal gcc header used when gcc is built (and not really important because gcc is written in C++ these days).  So unless this is a gcc plugin incorrectly built with C rather than C++ (dunno how that would work, most of the gcc headers used for plugins really just contain C++ specific constructs in them), you are not affected by that.

See https://gcc.gnu.org/gcc-15/porting_to.html for some details on the C23 switch, but in short, bool/true/false are now keywords like in C++, not macros defined in stdbool.h anymore.

Comment 8 Florian Weimer 2025-01-23 09:40:51 UTC
It's probably caused by this in src/mpack/conv.h:

#ifndef bool
# define bool unsigned
#endif

With GCC 15, bool is no longer defined as a macro even if <stdbool.h> is included.

Comment 9 Jakub Jelinek 2025-01-23 09:50:46 UTC
So, if you really want to keep that (note, unsigned is not just type incompatible with bool/_Bool, but has different size/alignment), then at least
#if !defined(bool) && __STDC_VERSION__ < 202311L
# define bool unsigned
#endif
(and better # define bool unsigned char, that at least has usually the same size/alignment).

Comment 10 Andreas Schneider 2025-01-23 10:44:49 UTC
Thanks for the help! This fixes it.

Comment 11 Fedora Update System 2025-01-23 12:21:38 UTC
FEDORA-2025-466f80ee8c (neovim-0.10.3-5.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-466f80ee8c

Comment 12 Fedora Update System 2025-01-23 12:46:25 UTC
FEDORA-2025-466f80ee8c (neovim-0.10.3-5.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.