leonarski_fandClaude Opus 5
2c1a459195
They were the last two dependencies a machine had to supply itself. Everything else - spdlog, zstd, HDF5, Catch2, libzmq, libtiff, FFTW, Ceres, the indexer, libcurl, libjpeg-turbo - the build fetches, so a checkout and a compiler were almost enough and then were not. Now they are: a plain Release configure needs neither zlib-devel nor eigen3-devel. Eigen is fetched as headers and never added as a subdirectory; a two-file config package is written into the build tree and Eigen3_DIR points at it, so Ceres and the indexer resolve their own find_package(Eigen3) through the ordinary config path. This is what makes it safe: OVERRIDE_FIND_PACKAGE remains banned, for the reason the note in CMakeLists has always given - it segfaults the CMake that ships with Visual Studio, one configure in three and every configure with Ceres CUDA on - and the shim never enters that code path at all, which the empty pkgRedirects directory in a configured build shows. The version file uses CMake's own AnyNewerVersion rather than Eigen's same-major rule, which is what declined Ceres' cross-major range and cost us a mixed-Eigen hunt in August. zlib is zlib-ng in compat mode, built during the configure into a prefix that FindZLIB is pointed at ahead of the system one. Built, not added as a subdirectory: libcurl puts ZLIB::ZLIB in CMAKE_REQUIRED_LIBRARIES and try_compile against an alias of an in-tree target is a hard error, so the viewer build breaks. A real archive has no such problem. It is forced position-independent, which the distro archive is and a default zlib-ng build is not - the xds plugin does not link otherwise. An existing installation still wins when it is asked for: -DZLIB_ROOT= and -DEigen3_DIR= configure as before and skip the fetches. About eighteen seconds on a first configure, nothing on a rebuild, and nothing added to the build itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011GxZqDiFP3KqriBhNdcR56
3.1 KiB
Software requirements
Operating system
Recommended operating system is Red Hat Enterprise Linux (RHEL) / Rocky Linux versions 8 or 9. For this operating systems we provide RPMs with pre-built binaries to simplify deployment. On experimental basis we also build repositories for Ubuntu 22.04 and 24.04.
Running Jungfraujoch on Red Hat Enterprise Linux 7 is currently not tested and not recommended, but likely possible with providing some packages from external repositories.
Two programs additionally run on Windows 11: the desktop viewer jfjoch_viewer, shipped as a
pre-built installer, and rugnux, the offline analysis CLI, shipped as a .zip. Both
can be built from source with Visual Studio 2026 (MSVC) and CUDA 13.3 — the viewer additionally
needs Qt 6.11; see
jfjoch_viewer ▸ Building from source on Windows.
The Windows artefacts bundle the Qt runtime (viewer only) and, on the CUDA builds, the cuFFT DLL, so
end users need neither Qt nor a CUDA toolkit installed — only an NVIDIA GPU driver for the GPU path.
On Linux the portable archives link CUDA entirely statically and so need nothing but the driver.
rugnux is also built for 64-bit Arm Linux (GH200, DGX Spark). The rest of Jungfraujoch is
Linux-only and x86-64-only. See Release contents for the CPU baseline and
CUDA requirements of each released package.
Software dependencies
Required:
- C++20 compiler and C++20 standard library; recommended GCC 11+ or clang 14+ (Intel OneAPI, AMD AOCC)
- CMake version 3.26 or newer + a build tool (GNU make or Ninja)
HDF5, libtiff, libjpeg-turbo, zlib and Eigen used to be required system packages; they are now downloaded and built automatically by CMake (see the note below), so none of them needs to be installed. No third-party library has to be provided by the host any more.
Optional:
- CUDA compiler version 12.8 or newer - required for the MX fast feedback indexer and GPU analysis
- FFTW library - for indexing if GPU/CUDA is absent (also auto-downloaded by CMake)
- Node.js - to build the frontend
- Qt version 6 (for jfjoch_viewer)
- OpenSSL 3.0 or newer and the Kerberos development headers (
krb5-devel/libkrb5-dev) - required to build jfjoch_viewer on Linux, where the fetched libcurl uses them for TLS and Negotiate; a build on OpenSSL 1.1 fails in libcurl
Many further dependencies (spdlog, Zstandard, HDF5, slsDetectorPackage, libzmq, libtiff,
libjpeg-turbo, Ceres, the fast feedback indexer, Catch2, ...) are downloaded automatically
by CMake and statically linked; building therefore requires network access on the first configure.
zlib (as zlib-ng in its zlib-compatible mode) and Eigen are among them: a copy already on the
machine is used instead if the configure is given -DZLIB_ROOT=<prefix> or -DEigen3_DIR=<dir>.
Others are vendored directly in the source tree. The complete list of third-party components, with
copyright holders, licenses and verbatim license texts, is in
Third-party software notices and the licenses/ directory.