Dear Support,
I am getting a cmake error when I try to build on a Centos 7 Box – Performing Test CHECK_HAVE_STAT64_STRUCT - Failed
The failed test shows
/usr/local/src/VTK/VTK-9.1.0.rc2/build/CMakeFiles/CMakeTmp/src.c:6:36: error: dereferencing pointer to incomplete type ‘struct stat64’
(void)sizeof(((struct stat64 *)0)->st_atime);
^~
I am using
cmake 3.21.3
gcc 8.1.0
I am not sure how to resolve this. Is anyone able to give me any hints?
thanks
Simon
That file exists : /usr/include/sys/stat.h
This is a Centos 7 box.and we have previously compiled vtk/7.0.0-gcc5
The CMAKE output was
cmake -DCMAKE_INSTALL_PREFIX=/usr/local/vtk/9.1.0 -DBUILD_SHARED_LIBS=ON -DVTK_USE_MPI=ON -DVTK_WRAP_PYTHON=ON -DVTK_PYTHON_VERSION=3 -DBUILD_TESTING=ON …
…
…
– Performing Test CHECK_HAVE_STAT64_STRUCT
– Performing Test CHECK_HAVE_STAT64_STRUCT - Failed
– Looking for localeconv
– Looking for localeconv - found
– Performing Test HAVE_PTHREAD_MUTEX_RECURSIVE_DEFN
– Performing Test HAVE_PTHREAD_MUTEX_RECURSIVE_DEFN - Success
– Configuring incomplete, errors occurred!
I had assumed the last failure was the cause of the problem, but looking again this may not be the case…I am afraid that as a new user I can not upload files,
Looking up the screen I now notice this…
– Check size of _Quad – Check size of _Quad - failed CMake Error at ThirdParty/hdf5/vtkhdf5/config/cmake/ConfigureChecks.cmake:367 (list):
** list index: 1 out of range (-1, 0)** Call Stack (most recent call first):
** ThirdParty/hdf5/vtkhdf5/CMakeLists.txt:503 (include)**
The otuput in the error file has this
/> usr/local/src/VTK/VTK-9.1.0.rc2/build/CMakeFiles/CheckTypeSize/_SIZEOF__QUAD.c:28:22: error: ‘_Quad’ undeclared here
(not in a function); did you mean ‘u_quad_t’? #define SIZE (sizeof(_Quad))
^~~~~
/usr/local/src/VTK/VTK-9.1.0.rc2/build/CMakeFiles/CheckTypeSize/_SIZEOF__QUAD.c:30:12: note: in expansion of macro ‘SI
ZE’
(‘0’ + ((SIZE / 10000)%10)),
^~~~
According to the bits of error log you sent, VTK is building its own internal hdf5 (which is its default) rather than using the hdf5 on your system. (VTK’s internal hdf5 is 1.12.1, I don’t know what version it needs for an external hdf5.)
In any case, the Check size of _Quad - failed message is not something to worry about. That particular test fails on my machine, too, but I can build VTK just fine. It’s just the CMake errors that you have to watch for.
It’s odd that the test program prints 21;0; but CMake complains list index: 1 out of range. Are you sure this is the first CMake Error that is printed? When debugging it’s important to go through the errors in order, starting at the top.
CMake Error at ThirdParty/hdf5/vtkhdf5/config/cmake/ConfigureChecks.cmake:367 (list):
list index: 1 out of range (-1, 0)
Call Stack (most recent call first):
ThirdParty/hdf5/vtkhdf5/CMakeLists.txt:503 (include)
Since the web page will not let me upload files, could I send you the full error log by some other means?
thanks
Simon
If that’s the first error, then it’s a good place to start, I don’t think the full log would be very enlightening given the information you’ve already sent.
We’ve already run the program that is supposed to provide the input to this list() command that is errorring, and it looks fine. So the next step is to instrument the ConfigureChecks.cmake file to get additional info.
Can you edit the file and add this “print” statement immediately before line 367?
message(STATUS "PROG_OUTPUT4: (${PROG_OUTPUT4})")
That will give tell us exactly what input is causing the list() command to fail. (There’s probably going to be a few more back-and-forths before we actually get to the root of the problem).
That’s interesting. I wonder why the test program segfaults when cmake compiles it, but it ran fine when you compiled it yourself? Maybe cmake is passing bad compiler flags?
In any case, you can substitute the known good output of that program in place of the segfault message. Try putting this immediately after the message() line that you just added:
set(PROG_OUTPUT4 21 0)
This should allow the list() command to succeed. Then we’ll know if it was the only issue.
There’s no log file for make, but tell make to show the commands it executes:
VERBOSE=1 make vtkFiltersParallelMPIPython
In this case, it will be vtkWrapPythonInit-9.1 but it will be interesting to see what args it’s being called with (since the args are making it crash).
One of the args will be this file in the build tree:
100%] Generating the Python module initialization sources for vtkFiltersParallelMPIPython
bin/vtkWrapPythonInit-9.1 /usr/local/src/VTK/VTK-9.1.0.rc2/build/CMakeFiles/vtkFiltersParallelMPIPythonPython/vtkFiltersParallelMPIPython-init.data /usr/local/src/VTK/VTK-9.1.0.rc2/build/CMakeFiles/vtkFiltersParallelMPIPythonPython/vtkFiltersParallelMPIPythonInit.cxx /usr/local/src/VTK/VTK-9.1.0.rc2/build/CMakeFiles/vtkFiltersParallelMPIPythonPython/vtkFiltersParallelMPIPythonInitImpl.cxx
make[3]: *** [CMakeFiles/vtkFiltersParallelMPIPythonPython/vtkFiltersParallelMPIPythonInit.cxx] Segmentation fault (core dumped)
dmesg -T shows
[Fri Oct 15 11:56:58 2021] vtkWrapPythonIn[20608]: segfault at b8 ip 00007f7a33fc095e sp 00007ffc49dcbd48 error 4 in libc-2.17.so[7f7a33f31000+1c4000]
[Fri Oct 15 12:17:47 2021] vtkWrapPythonIn[26228]: segfault at b8 ip 00007f8977fbe95e sp 00007ffd7bedf1a8 error 4 in libc-2.17.so[7f8977f2f000+1c4000]
The contents of CMakeFiles/vtkFiltersParallelMPIPythonPython/vtkFiltersParallelMPIPython-init.data
The dmesg commands make me thinks it is a library issue but all other modules (i.e. python, cmake )in the system were built with gcc8 so I am not sure where to begin.
Well, it’s vaguely possible that some bits got flipped on disk. You can try rpm -V to verify the checksums for the glibc and gcc packages.
For vtkWrapPythonInit-9.1, since its input looks fine and since you have the command line, I think the next step should be to run the command line in gdb and get a stack trace. And if that doesn’t give any useful info, then recompile in debug mode and try the debugger again.
David
sadly this did not produce any meaningful information. I will try without MPI and see if I can get a single server version going. Maybe try different versions of MPI.
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “x86_64-redhat-linux-gnu”.
For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/…
Reading symbols from /usr/local/src/VTK/VTK-9.1.0.rc2/build/bin/vtkWrapPythonInit-9.1…done.
(gdb) run /usr/local/src/VTK/VTK-9.1.0.rc2/build/CMakeFiles/vtkFiltersParallelMPIPythonPython/vtkFiltersParallelMPIPython-init.data /usr/local/src/VTK/VTK-9.1.0.rc2/build/CMakeFiles/vtkFiltersParallelMPIPythonPython/vtkFiltersParallelMPIPythonInit.cxx /usr/local/src/VTK/VTK-9.1.0.rc2/build/CMakeFiles/vtkFiltersParallelMPIPythonPython/vtkFiltersParallelMPIPythonInitImpl.cxx
Starting program: /usr/local/src/VTK/VTK-9.1.0.rc2/build/bin/vtkWrapPythonInit-9.1 /usr/local/src/VTK/VTK-9.1.0.rc2/build/CMakeFiles/vtkFiltersParallelMPIPythonPython/vtkFiltersParallelMPIPython-init.data /usr/local/src/VTK/VTK-9.1.0.rc2/build/CMakeFiles/vtkFiltersParallelMPIPythonPython/vtkFiltersParallelMPIPythonInit.cxx /usr/local/src/VTK/VTK-9.1.0.rc2/build/CMakeFiles/vtkFiltersParallelMPIPythonPython/vtkFiltersParallelMPIPythonInitImpl.cxx
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7a9c95e in ?? ()
Missing separate debuginfos, use: debuginfo-install glibc-2.17-324.el7_9.x86_64
(gdb) where #0 0x00007ffff7a9c95e in ?? () #1 0x00007ffff7de7b03 in _dl_relocate_object () from /lib64/ld-linux-x86-64.so.2 #2 0x00007ffff7ddf99a in dl_main () from /lib64/ld-linux-x86-64.so.2 #3 0x00007ffff7df300e in _dl_sysdep_start () from /lib64/ld-linux-x86-64.so.2 #4 0x00007ffff7ddcbd1 in _dl_start () from /lib64/ld-linux-x86-64.so.2 #5 0x00007ffff7ddc148 in _start () from /lib64/ld-linux-x86-64.so.2 #6 0x0000000000000004 in ?? () #7 0x00007fffffffd16c in ?? () #8 0x00007fffffffd1ad in ?? () #9 0x00007fffffffd227 in ?? () #10 0x00007fffffffd29f in ?? () #11 0x0000000000000000 in ?? ()
This seems…bad. However, it is also not actually in VTK’s code (yet?). I think something went very wrong here. Can you run it at the command line with LD_DEBUG=libs in the environment? That output should show what libraries it is using.