Bug 2341189

Created attachment 2072087 [details]
build.log

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

Created attachment 2072088 [details]
root.log

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

Created attachment 2072089 [details]
state.log

I see:

In file included from /usr/include/section.h:37,
                 from adexp.c:11:
adexp.c:42:25: error: conflicting types for ‘hoc_getarg’; have ‘double *(void)’
   42 |          extern double *getarg();
      |                         ^~~~~~
In file included from /usr/include/section.h:37,
                 from alphaisyn.c:11:
alphaisyn.c:41:25: error: conflicting types for ‘hoc_getarg’; have ‘double *(void)’
   41 |          extern double *getarg();
      |                         ^~~~~~
/usr/include/oc_ansi.h:49:16: note: previous declaration of ‘hoc_getarg’ with type ‘double *(int)’
   49 | extern double* getarg(int);
      |                ^~~~~~
/usr/include/oc_ansi.h:49:16: note: previous declaration of ‘hoc_getarg’ with type ‘double *(int)’
   49 | extern double* getarg(int);
      |                ^~~~~~
alphaisyn.c: In function ‘_hoc_update_queue’:
alphaisyn.c:260:50: error: too many arguments to function ‘hoc_getarg’; expected 0, have 1
  260 |  _r =  update_queue ( _p, _ppvar, _thread, _nt, *getarg(1) );
      |                                                  ^~~~~~
alphaisyn.c:41:25: note: declared here
   41 |          extern double *getarg();
      |                         ^~~~~~
alphaisyn.c: In function ‘_hoc_alpha’:
alphaisyn.c:283:43: error: too many arguments to function ‘hoc_getarg’; expected 0, have 1
  283 |  _r =  alpha ( _p, _ppvar, _thread, _nt, *getarg(1) );
      |                                           ^~~~~~
alphaisyn.c:41:25: note: declared here
   41 |          extern double *getarg();
      |                         ^~~~~~
alphaisyn.c: In function ‘_net_receive__AlphaISyn’:
alphaisyn.c:290:32: error: conflicting types for ‘hoc_object_name’; have ‘char *(void)’
  290 |   if (_tsav > t){ extern char* hoc_object_name(); hoc_execerror(hoc_object_name(_pnt->ob), ":Event arrived out of order. Must call ParallelContext.set_maxstep AFTER assigning minimum NetCon.delay");}
      |                                ^~~~~~~~~~~~~~~
In file included from /usr/include/hocdec.h:280:
/usr/include/oc_ansi.h:46:14: note: previous declaration of ‘hoc_object_name’ with type ‘char *(Object *)’
   46 | extern char* hoc_object_name(Object*);
      |              ^~~~~~~~~~~~~~~
adexp.c: In function ‘_hoc_exp_current’:
alphaisyn.c:290:65: error: too many arguments to function ‘hoc_object_name’; expected 0, have 1
  290 |   if (_tsav > t){ extern char* hoc_object_name(); hoc_execerror(hoc_object_name(_pnt->ob), ":Event arrived out of order. Must call ParallelContext.set_maxstep AFTER assigning minimum NetCon.delay");}
      |                                                                 ^~~~~~~~~~~~~~~ ~~~~~~~~
alphaisyn.c:290:32: note: declared here
  290 |   if (_tsav > t){ extern char* hoc_object_name(); hoc_execerror(hoc_object_name(_pnt->ob), ":Event arrived out of order. Must call ParallelContext.set_maxstep AFTER assigning minimum NetCon.delay");}
      |                                ^~~~~~~~~~~~~~~
adexp.c:408:49: error: too many arguments to function ‘hoc_getarg’; expected 0, have 1
  408 |  _r =  exp_current ( _p, _ppvar, _thread, _nt, *getarg(1) );
      |                                                 ^~~~~~
adexp.c:42:25: note: declared here
   42 |          extern double *getarg();
      |                         ^~~~~~

[… etc. etc. etc.]

These are GCC 15 / C23 issues, where pointers to functions-of-unspecified arguments are used interchangeably with pointers to functions-of-particular-arguments (and the same return type), but C23 treats "int foo()" as a nullary function like "int foo(void)". Most or all of the problems appear to be coming from neuron headers.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.

FEDORA-2025-d1fa51e383 (neuron-8.2.6-2.fc42, python-netpyne-1.0.7-5.fc42, and 1 more) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-d1fa51e383

FEDORA-2025-d1fa51e383 has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-d1fa51e383`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-d1fa51e383

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2025-d1fa51e383 (neuron-8.2.6-2.fc42, python-netpyne-1.0.7-5.fc42, and 1 more) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.