Hey everyone, my main desktop computer is running Centos-8, so I’m able to build the recent clones from git on that machine, but when I then shift to the system that drives our CAVE, it is only at Centos 7,9, which has GCC version 4.8.5. I’ve had a conversation with Cory through another channel, and I understand that there are issues with the 4.8.5 compiler. I should point out that the Qt package on the Centos 7.9 system is 5.9.7.
I’ve tried a couple different things, but have not been able to get a successful compile of a recent git clone on the Centos 7.9 machine.
I’m trying two different versions of the git clone – one from last month (11/09/20), and one from this morning (12/04/20).
Here are the things I’ve tried:
On the 11/09/20 git clone, there is an issue with at least one file initializing a variable inside a for loop, which was added to C at the C99 version. As this file seems to be part of ExodusII, I tried to remove all the ExodusII options in ccmake. But when I do that I’m told: The VTK::IOParallelExodus module requires the disabled module VTK::IOExodus.
the odd thing is that I also disabled the VTK::IOParallelExodus module too, so I don’t know why CMake insists that it requires the standard VTK::IOExodus module.
Another suggestion (thanks Cory!) was to force CMake to use “-std:C99” in the build process, so I did this: % cmake -DPARAVIEW_EXTRA_CMAKE_ARGUMENTS:STRING="-DCMAKE_C_FLAGS:STRING=-std=c99" ..
but CMake complained: CMake Warning: Manually-specified variables were not used by the project: PARAVIEW_EXTRA_CMAKE_ARGUMENTS
so that seems to be failing.
And next I switched to the git clone from today (12/04/20), but it complains about the version of QT on my system – it wants version 5.12, but the system just has version 5.9.7. So I can’t win!
Finally, another suggestion was to edit the CMakeLists.txt file for force the -std=c99" option in the 11/09/20 version, but I’m afraid I’m not that experienced with CMake to make that edit. So if anyone can suggest that edit, that would be great.
Also, I guess I don’t know how long Centos-8 has been around, but I do know that while we are in the process of upgrading the CAVE to a Centos-8 system there are older software that we still need to migrate, so seems like it might still be a bit early to abandon Centos-7.
Thanks for the info. I’ll comment on a couple of the particulars below, but the executive summary is that I tried the CMAKE_C_FLAGS:STRING=-std=c99 suggestion, and while I no longer get the complaint of variable declaration inside a for loop, the file “vtksys/ProcessUNIX.c” generated several warnings and fatal errors. I fixed one, but most seemed to be missing a header file and it wasn’t obvious which one (since “signal.h” itself is included). So, we’re working on bringing up one of our systems connected to the CAVE to Centos-8, and I will wait for that to complete before continuing my work on ParaView there.
But I also wanted to mention:
I did actually set all the “exodus” related modules to “NO”, but still got the complaint that the IOExodus module was required, so seems like a possible bug in the CMakeLists.txt file.
Very recently it would seem since my git clone from November 9th didn’t seem to require it! I’m definitely not going to try compiling a new version of Qt on the old Centos-7.9 machine. I tried doing a Qt build on a Centos-8 machine not that long ago, and never got past trying to get the “Qt5X11Extras” module built – no matter how much I Googled. So I’m relying on packaged versions of Qt only.
Okay, can I ask for a clarification on that? I’m not sure what you mean by “linked MR”
And to revisit on issue from the original post, I’m back to compiling the git clone I made on 11/09/2020, and I’m using this extra string (-DCMAKE_C_FLAGS:STRING="-std=c11 -D_GNU_SOURCE") which I found on a VTK-related forum. That gets me to 96% of the way through the build when I then encounter (maybe TMI):
.../ParaView-VR_git-20201109/Qt/ApplicationComponents/pqDataAssemblyPropertyWidget.cxx: In constructor ‘pqDataAssemblyPropertyWidget::pqDataAssemblyPropertyWidget(vtkSMProxy*, vtkSMPropertyGroup*, QWidget*)’:
.../ParaView-VR_git-20201109/Qt/ApplicationComponents/pqDataAssemblyPropertyWidget.cxx:214:58: error: no matching function for call to ‘pqDataAssemblyPropertyWidget::connect(QPointer<pqDataAssemblyTreeModel>&, void (pqDataAssemblyTreeModel::*)(int), pqDataAssemblyPropertyWidget* const, void (pqDataAssemblyPropertyWidget::*)(int))’
.../ParaView-VR_git-20201109/Qt/ApplicationComponents/pqDataAssemblyPropertyWidget.cxx:214:58: note: candidates are:
In file included from /usr/include/qt5/QtCore/QObject:1:0,
/usr/include/qt5/QtCore/qobject.h:214:36: note: static QMetaObject::Connection QObject::connect(const QObject*, const char*, const QObject*, const char*, Qt::ConnectionType)
static QMetaObject::Connection connect(const QObject *sender, const char *signal,
/usr/include/qt5/QtCore/qobject.h:214:36: note: no known conversion for argument 2 from ‘void (pqDataAssemblyTreeModel::*)(int)’ to ‘const char*’
/usr/include/qt5/QtCore/qobject.h:217:36: note: static QMetaObject::Connection QObject::connect(const QObject*, const QMetaMethod&, const QObject*, const QMetaMethod&, Qt::ConnectionType)
static QMetaObject::Connection connect(const QObject *sender, const QMetaMethod &signal,
So I’m guessing maybe this is because my version of Qt isn’t new enough, but the CMakeLists.txt file hadn’t caught up to that yet.
(P.S. I don’t know whether I got the code quoting right as no tags show up in the edit window.)