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.
That looks like it was a suggestion for the superbuild. Just -DCMAKE_C_FLAGS= rather than wrapping it in PARAVIEW_EXTRA_CMAKE_ARGUMENTS would probably help.
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.
ParaView-wide C99 might be a bit ambitious. If you make the changes in the linked MR to your ParaView source, you shouldn’t need to pass the flag anymore.
Makes sense. Not all modules can be turned off since some are considered “core” ParaView functionality.
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))’
&pqDataAssemblyPropertyWidget::assemblyTreeModified);
^
.../ParaView-VR_git-20201109/Qt/ApplicationComponents/pqDataAssemblyPropertyWidget.cxx:214:58: note: candidates are:
In file included from /usr/include/qt5/QtCore/QObject:1:0,
from .../ParaView-VR_git-20201109/Qt/Core/pqPropertyLinks.h:35,
from .../ParaView-VR_git-20201109/Qt/Components/pqPropertyWidget.h:38,
from .../ParaView-VR_git-20201109/Qt/ApplicationComponents/pqDataAssemblyPropertyWidget.h:36,
from .../ParaView-VR_git-20201109/Qt/ApplicationComponents/pqDataAssemblyPropertyWidget.cxx:32:
/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.)