Fedora 41 compilation error cflscandir.c
Error from colleague compiling on Fedora 41
gcc -DUNDERSCORE -DLinux -I/home/gempak/GEMPAK7/gempak/include -I/home/gempak/GEMPAK7/os/linux64/include -I/usr/X11R6/include -DG_64BIT -g -O2 -fPIC -c cflscandir.c
cflscandir.c: In function ‘cfl_scandir’:
cflscandir.c:82:61: error: passing argument 4 of ‘scandir’ from incompatible pointer type [-Wincompatible-pointer-types]
82 | n_entries = scandir(_cflrdirPath, namelist, filter, compar);
| ^~~~~~
| |
| int (*)(const void *, const void *)
In file included from /home/gempak/GEMPAK7/gempak/include/geminc.h:24,
from cflscandir.c:1:
/usr/include/dirent.h:260:27: note: expected ‘int (*)(const struct dirent **, const struct dirent **)’ but argument is of type ‘int (*)(const void *, const void *)’
260 | int (*__cmp) (const struct dirent **,
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
261 | const struct dirent **))
| ~~~~~~~~~~~~~~~~~~~~~~~
make[4]: *** [Makefile:52: /home/gempak/GEMPAK7/os/linux64/lib/cgemlib.a(cflscandir.o)] Error 1
make[4]: Leaving directory '/home/gempak/GEMPAK7/gempak/source/gemlib/cfl'
Making all in /home/gempak/GEMPAK7/gempak/source/gemlib/ctb
make[4]: Entering directory '/home/gempak/GEMPAK7/gempak/source/gemlib/ctb'
This reminds me, I recently tried to install Gempak on Ubuntu 24.04 LTS and it failed, though these particular errors do not look familiar to me. It made me think in the moment that there might be something else going on, some new dependency we're missing or some compiler configuration. In fact, it's possible that #154 should be reopened as I thought I saw quite a bit of similarity there (go figure).
All this is to say I wonder how related these recent install issues are. Given the versions of gfortran Gempak tends to prefer makes me suspect it's likely, but that's just a hunch. I need to figure that 24.04 issue out anyways so I'll keep this one in mind as well. When (not if I swear) I get into the weeds on this I'll open/update issues here as needed.
Thanks for reporting! And for reminding me I have work to do here! 👍
Looking at the porting guide, I think adding yet another compiler flag (-Wno-error=incompatible-pointer-types in this case) will "fix" this. The true fix as always would be to change the code appropriately, but not being a C programmer I can't say how to do it. This case does look similar to the callback function example on that page, but instead of char ** as in that example we have const struct dirent **.