Documentation: Update instructions for EL9, etc
I recently tried building GeoModel inside an EL9 container (setupATLAS -c el9
) and found a few issues with the instructions. In general Centos7 should be removed from the documentation and updated for EL9, given that support for Centos7 is being dropped by CERN. I thought these and a few other points might be useful to report ahead of the documentation week in case
- Instructions here should point to a newer LCG version which supports EL9.
- If one is building
simage
is the patch reported as necessary for EL9 also? I think so based on my experience - I got the following when I tried without it:
cmake -DCMAKE_INSTALL_PREFIX=../install -DSIMAGE_BUILD_DOCUMENTATION=0 -DSIMAGE_BUILD_EXAMPLES=0 -DSIMAGE_LIBSNDFILE_SUPPORT=0 -DSIMAGE_MPEG2ENC_SUPPORT=0 -DSIMAGE_OGGVORBIS_SUPPORT=0 ../simage
[...]
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find GIF (missing: GIF_LIBRARY GIF_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake/Modules/FindGIF.cmake:109 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:279 (find_package)
-- Configuring incomplete, errors occurred!
I don't know that this is the same problem as the patch solves, but in any case it seems not to work out-of-the-box?
- When installing GeoModel via the following to use all the built-in externals:
cmake -DCMAKE_INSTALL_PREFIX=../install -DGEOMODEL_USE_BUILTIN_EIGEN3=1 -DGEOMODEL_USE_BUILTIN_XERCESC=1 -DGEOMODEL_USE_BUILTIN_JSON=1 -DGEOMODEL_USE_BUILTIN_COIN3D=1 -DGEOMODEL_BUILD_VISUALIZATION=1 -DGEOMODEL_BUILD_TOOLS=1 ../GeoModel/
it seems to all compile fine, but at runtime I see:
Apptainer> ../install/bin/gmex
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-nstyles'
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
VP1MESSAGE: Successfully loaded libGXGeometryPlugin.so
VP1MESSAGE: providing channels: Geometry
VP1MESSAGE: Geometry/Geo: VP1GeometrySystem::buildController
and gmex
fails with the message that it can't open a valid OpenGL canvas. Is this a known issue? Perhaps an issue specific to the container? I will try again on lxplus where I can run natively in EL9 to check.
- Not EL9 specific (I think), but the handling of external dependencies is a bit unclear... to me the documentation implies that either using the built-in third-party packages OR using an LCG release should mean one can "easily set up a recent version of CMake, Qt and all the other dependency packages ... After that, you can build the
GeoModel
without any extra options." and while for the built-in versions that seems to work up to the run-time issue I mention fromlibGL
, after setting up a recent (EL9-compatible) LCG release (LCG_104d
) I see:
-- Building GeoModelVisualization as part of the root GeoModel project.
CMake Error at cmake/SetupCoin3D.cmake:113 (find_package):
By not providing "FindCoin.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Coin", but
CMake did not find one.
Could not find a package configuration file provided by "Coin" with any of
the following names:
CoinConfig.cmake
coin-config.cmake
Add the installation prefix of "Coin" to CMAKE_PREFIX_PATH or set
"Coin_DIR" to a directory containing one of the above files. If "Coin"
provides a separate development package or SDK, be sure it has been
installed.
Call Stack (most recent call first):
GeoModelVisualization/CMakeLists.txt:67 (include)
so this doesn't seem to work out-of-the-box for Coin
.
- In the "Post install settings" all of the paths to the
install
directory are given as relative paths like.../install
. I guess this is to avoid any issues of the precise paths that people have used? The problem is that then if anyone tries to run in a slightly different location then files will not be found. It might be better then to provide instructions with an obvious placeholder path, so that it will be clear to people that they should set it to the correct thing for where they built the code, and that it should be a full path ideally to avoid run-time issues?