Repository navigation
Install issues with gcc-14.1 #169
Description
Activity
I can confirm that it works as intended with an overall older OS version (e.g.
toolbox create --release 39, which will recreate an environment representing a past Fedora version).It really is something about the new set of tools.
Ah. Got it: Handling of implicit function declarations, new in GCC-14:
It is no longer possible to call a function that has not been declared. [...]
I guess this means either a lot of code fixing, or sticking to GCC <= 13 for another decade or so... 🤦
This is a bit of a pain because devIocStats is an external dependency, so fixing this is not as simple as fixing our code. It's probably worth raising an issue with devIocStats and cross-linking here. Presumably you can check that this is the only error by adding the appropriate
#includeto your local checkout and checking that building then works.I suppose we could do some kind of patch to the checked out dependency before building it?
The preferred fix is probably to implement #106.
pythonSoftIOC fails to build on Debian 13 (py3.13, GCC 14.2) due to this issue. The present bundled iocStats version (epics-modules/iocStats@4df9e87) is 6+ years old. The latest iocStats (epics-modules/iocStats@078205e) builds correctly for me.
My initial diagnosis was incorrect. There is a straightforward issue with the bundling process.
iocStats/devIocStats/os/posix/devIocStatsOSD.hincludesstdlib.h. However,os/posix/is not being included in sdist, so instead the defaultdevIocStatsOSD.hin found, which does not includestdlib.h. #199 fixes this, and also updates the bundled iocStats.#199 has been merged, closing this issue
Hello,
pip installwill bug out with the following error for me:Essentially,
gccis right: there's no<stdlib.h>indevIocStatsSub.c. I'm guessing it's a 14 year old upstream error of EPICS.I don't know why it used to work until now, but it might have something to do with the fact that it's a gcc 14.1 environment?... Maybe something changed in the way the standard prototype is being interpreted (which I belive is
int malloc(), with()generally meaning "no arguments", but also being a valid replacement for "(...)" in the past -- maybe not anymore?)Or it's because of Python 3.12.4, the one I'm using?
I'm running this on what most likely amounts to a clean install of Fedora 40. (Technically, it's a freshly created "Toolbox" on a recent "Fedora CoreOS"...) Here is the complete script to reproduce:
Cheers,
F.