error: identifier "siginfo_t" is undefined

[FritzPeppone]

I'm getting an error trying to compile GKlib on a CentOS 7 cluster (therefore, I have to build it myself) using cmake 3.6.1 and gcc 8.1.0. The error while executing make reads as follows:

[ 47%] Building C object CMakeFiles/GKlib.dir/string.c.o
/apps/gcc/gcc-8.1.0-x86_64/bin/gcc   -I/home/hpc/iwsp/iwsp041h/PBFSim_Debug/GKlib/. -I/home/hpc/iwsp/iwsp041h/PBFSim_Debug/GKlib/test  -DLINUX -D_FILE_OFFSET_BITS=64 -std=c99 -fno-strict-aliasing -march=native -fPIC -Werror -Wall -pedantic -Wno-unused-function -Wno-unused-but-set-variable -Wno-unused-variable -Wno-unknown-pragmas -Wno-unused-label -DNDEBUG -DNDEBUG2 -DHAVE_EXECINFO_H -DHAVE_GETLINE -O3   -o CMakeFiles/GKlib.dir/string.c.o   -c /home/hpc/iwsp/iwsp041h/PBFSim_Debug/GKlib/string.c
In file included from /home/hpc/iwsp/iwsp041h/PBFSim_Debug/GKlib/./GKlib.h:41,
                 from /home/hpc/iwsp/iwsp041h/PBFSim_Debug/GKlib/string.c:21:
/usr/include/signal.h:156:29: Fehler: unbekannter Typname: »siginfo_t«
 extern void psiginfo (const siginfo_t *__pinfo, const char *__s);
                             ^~~~~~~~~
make[3]: *** [CMakeFiles/GKlib.dir/string.c.o] Fehler 1
make[3]: Leaving directory `/home/hpc/iwsp/iwsp041h/PBFSim_Debug/GKlib/build/Linux-x86_64'
make[2]: *** [CMakeFiles/GKlib.dir/all] Fehler 2
make[2]: Leaving directory `/home/hpc/iwsp/iwsp041h/PBFSim_Debug/GKlib/build/Linux-x86_64'
make[1]: *** [all] Fehler 2
make[1]: Leaving directory `/home/hpc/iwsp/iwsp041h/PBFSim_Debug/GKlib/build/Linux-x86_64'
make: *** [all] Fehler 2

Does anyone know a solution to this issue?

[FritzPeppone]

I found a workaround for this issue! The latest commit (Jan. 2022, valgrind) added changes in string.c. Here, the feature test macro _XOPEN_SOURCE is defined, then time.h include and _XOPEN_SOURCE is undefined again. This undefining seems to lead to inconsistencies when including headers later.
I was able to build GKlib on my Cluster by using an older commit (1403a04) which built without any issues.

However I should add, that this build issue only turned up when I tried to build on Cluster. On my local (Ubuntu) machine, both versions compiled without any problems.
I'd be happy to provide more information on this, if required to solve the issue in the latest version.

[nourgaliev]

I have the same issue on our toss3 system.

[nourgaliev]

Commenting out also fixed the problem.

[nourgaliev]

This got to be fixed properly.

[Jeff-Hadley]

I also ran into the same issue. If you're trying to build GKlib for use with METIS, using the next commit (33b8c8b) along with the current master branch of METIS seems to have worked on our cluster.

[nourgaliev]

It does not look like GKlib was updated lately. Which branch you are talking about?

[nourgaliev]

This commit is from January. I made a fresh new clone from master branch in May - still having the issue.

[nourgaliev]

(Unless it was not merged to master...)

[Jeff-Hadley]

Sorry, I originally misspoke, our cluster is running Debian and not CentOS, however I was getting the same siginfo_t is undefined error.

As for branch and the commits: The latest commit (a7f8172 from January 30th) on the master branch was causing the siginfo_t issue for us due to some of the changes to the string.h file. I was able to successfully compile the the earlier 33b8c8b commit from Jan 8th and use that build with the most up to date master branch of METIS (commit 94c03a6). The 1403a04 GKlib commit previously suggested as a solution was causing errors when trying to link with the most up to date version of METIS.

[nourgaliev]

OK. Livermore Computing is using toss3 (transitioning to toss4), RedHat. The solution I have for the latest versions of both MeTiS and GKLib is to comment out these lines. This is not really a solution, rather bandaids. I think the one who put these lines needs to figure out a proper fix.

[nourgaliev]

It might not be OS related, but rather compiler related. I am building with the latest oneAPI intel compiler. I have not tested if this is needed for gcc11 and clang12. Apparently, commenting these out works for all 3 compilers I am using on toss3.

[jverdicchio]

I also ran into the same issue. If you're trying to build GKlib for use with METIS, using the next commit (33b8c8b) along with the current master branch of METIS seems to have worked on our cluster.

From a clean "git clone" I attempted to build GKlib on CentOS 7 with gnu9.2 I obtained the same problem and the same fix (early version checkout) also worked.

[vidurayashan]

I found a workaround for this issue! The latest commit (Jan. 2022, valgrind) added changes in string.c. Here, the feature test macro _XOPEN_SOURCE is defined, then time.h include and _XOPEN_SOURCE is undefined again. This undefining seems to lead to inconsistencies when including headers later. I was able to build GKlib on my Cluster by using an older commit (1403a04) which built without any issues.

However I should add, that this build issue only turned up when I tried to build on Cluster. On my local (Ubuntu) machine, both versions compiled without any problems. I'd be happy to provide more information on this, if required to solve the issue in the latest version.

Worked for me on CentOS 7

[tormentliang]

Also hit by this, finally I found the reason:
The siginfo_t type conforms to IEEE Std 1003.1-2004 ("POSIX.1").

A _POSIX_C_SOURCE version should be set for the preprocessor to activate siginfo_t.
Adding set(GKlib_COPTIONS "${GKlib_COPTIONS} -D_POSIX_C_SOURCE=199309L") to GKlibSystem.cmake works for me.

[Fern-Parker]

I also ran into the same issue. If you're trying to build GKlib for use with METIS, using the next commit (33b8c8b) along with the current master branch of METIS seems to have worked on our cluster.

Worked for me on CentOS7

[tianninglyu]

Also hit by this, finally I found the reason: The siginfo_t type conforms to IEEE Std 1003.1-2004 ("POSIX.1").

A _POSIX_C_SOURCE version should be set for the preprocessor to activate siginfo_t. Adding set(GKlib_COPTIONS "${GKlib_COPTIONS} -D_POSIX_C_SOURCE=199309L") to GKlibSystem.cmake works for me.

It's a pity that this doesn't work for me... Do you have any other ideas? Any help will be highly appreciated.