leonarski_fandClaude Opus 5
8d32024dd1
Build Packages / build:rugnux:windows (push) Failing after 2s
Build Packages / build:rugnux-tgz (x86_64) (push) Failing after 14s
Build Packages / build:rugnux:aarch64 (cross) (push) Failing after 30s
Build Packages / Unit tests (push) Canceled after 2m33s
Build Packages / build:rpm (rocky8) (push) Canceled after 0s
Build Packages / build:rpm (rocky9_sls9) (push) Canceled after 0s
Build Packages / build:rpm (rocky9) (push) Canceled after 0s
Build Packages / build:rpm (ubuntu2204) (push) Canceled after 0s
Build Packages / build:rpm (ubuntu2404) (push) Canceled after 0s
Build Packages / DIALS test (push) Canceled after 0s
Build Packages / XDS test (durin plugin) (push) Canceled after 0s
Build Packages / XDS test (JFJoch plugin) (push) Canceled after 0s
Build Packages / XDS test (neggia plugin) (push) Canceled after 0s
Build Packages / Generate python client (push) Canceled after 0s
Build Packages / build:viewer-tgz:cuda (push) Canceled after 2m29s
Build Packages / Build documentation (push) Canceled after 0s
Build Packages / Create release (push) Canceled after 0s
Build Packages / build:rpm (ubuntu2204_nocuda) (push) Canceled after 2m19s
Build Packages / build:viewer-tgz:cpu (push) Canceled after 2m31s
Build Packages / build:rpm (rocky8_sls9) (push) Canceled after 1m54s
Build Packages / build:rpm (rocky9_nocuda) (push) Canceled after 2m21s
Build Packages / build:rpm (rocky8_nocuda) (push) Canceled after 2m23s
Build Packages / build:rpm (ubuntu2404_nocuda) (push) Canceled after 2m13s
Build Packages / build:windows:cuda (push) Canceled after 2m42s
Build Packages / build:windows:nocuda (push) Canceled after 2m45s
The viewer tarball also carried rugnux, jfjoch_extract_hkl and jfjoch_recompress. A GUI download that contains a batch processor is confusing on its own, and it forced anyone who only wanted rugnux to take Qt with it. JFJOCH_RUGNUX_ONLY is the viewer-only subtree minus viewer/ and tools/, so it needs no Qt at all, and each of the two options now yields one artifact holding one program: JFJOCH_VIEWER_ONLY jfjoch_viewer .tar.gz / installer / .dmg JFJOCH_RUGNUX_ONLY rugnux .tar.gz / .zip The two CLI tools are still built and no longer installed anywhere. rugnux gets a CPack component of its own, so its notices land in share/doc/jfjoch_rugnux. What makes the split possible is linking cuFFT statically in both products. It was the only CUDA component still dynamic - cudart and the fast-feedback indexer were already static - and shipping it as a .so meant each self-contained archive had to carry the library beside its executables and find it again through an $ORIGIN rpath. That rpath was set on jfjoch_viewer alone, while the same tarball installed three more executables, so those shipped with no runpath at all (cmake strips the build-tree one, which points at the build host's CUDA directory) and could not load the libcufft lying next to them. Static, an artifact is one file that runs: the x86_64 rugnux tarball needs only libc, libstdc++, libgcc_s, libm, libpthread, librt and libdl. The bundling code and the rpath both go away. libcufft_static.a carries a relocatable-device-code object, so a consuming executable needs a CUDA device link; CUDA 13 no longer ships the libcufft_static_nocallback.a that used to avoid this. CUDA_RESOLVE_DEVICE_SYMBOLS emits that step while leaving the host link driver alone, so the -march and -flto flags CI passes still apply. The server build keeps the shared library: its .deb/.rpm take CUDA from the distro, and every executable there would otherwise need the same device link. The guards that exclude server-side targets keyed on NOT JFJOCH_VIEWER_ONLY, which a rugnux-only build does not satisfy - it failed on jfjoch_writer pulling in JFJochImagePuller. They now key on JFJOCH_PORTABLE_ONLY, true for either product, rather than on one product's option in five places. docker/ubuntu2404 additionally cross-compiles rugnux for arm64 SBSA, which is both DGX Spark (GB10, sm_121) and Grace Hopper (GH200, sm_90); one binary with both fatbins runs on either. It needed three things beyond a cross gcc. arm64 is published on ports.ubuntu.com and Noble's deb822 sources carry no Architectures: field, so adding the architecture without splitting the entries 404s on every index. The CUDA cross packages are in neither the x86_64 repo nor the sbsa one but in cross-linux-sbsa, whose fatbinary_section.h ships only in the x86_64 target tree even though it is architecture-neutral. And HDF5 has two try_run probes, so qemu-user-static is needed as CMAKE_CROSSCOMPILING_EMULATOR; every other fetched dependency either guards its run-checks or has none. The cross-built tarball is one ELF aarch64 binary carrying all 17 GPU modules for both sm_90 and sm_121, needing no cuFFT and no CUDA runtime at run time. It is untested on hardware: XDS is x86-64 only, so CI can show it links but only a Spark or a GH200 can show it works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQjneRUssfhi1k9rq8Ts3h
63 lines
2.8 KiB
CMake
63 lines
2.8 KiB
CMake
ADD_LIBRARY(JFJochIndexing STATIC
|
|
Indexer.h
|
|
Indexer.cpp
|
|
IndexerFactory.h
|
|
IndexerFactory.cpp
|
|
IndexerThreadPool.cpp
|
|
IndexerThreadPool.h
|
|
AnalyzeIndexing.cpp
|
|
AnalyzeIndexing.h
|
|
FitProfileRadius.cpp
|
|
FitProfileRadius.h
|
|
PostIndexingRefinement.h
|
|
FFTResult.h
|
|
FFTIndexer.cpp
|
|
FFTIndexer.h
|
|
PostIndexingRefinement.cpp
|
|
MultiLatticeSearch.cpp
|
|
MultiLatticeSearch.h)
|
|
TARGET_LINK_LIBRARIES(JFJochIndexing JFJochCommon JFJochLatticeSearch)
|
|
|
|
IF (JFJOCH_CUDA_AVAILABLE)
|
|
# GIT_SUBMODULES "" -> do not fetch ffbidx's bundled eigen submodule; it would add_subdirectory
|
|
# a second Eigen3::Eigen target. ffbidx instead resolves Eigen via the project-level Eigen3
|
|
# (the find_package(Eigen3) at the top of image_analysis/CMakeLists.txt).
|
|
FetchContent_Declare(
|
|
fast-indexer
|
|
GIT_REPOSITORY https://github.com/paulscherrerinstitute/fast-feedback-indexer/
|
|
GIT_TAG a94fd4f5c55289e70860feea358182d2072e02b5
|
|
GIT_SUBMODULES ""
|
|
)
|
|
|
|
FetchContent_MakeAvailable(fast-indexer)
|
|
TARGET_SOURCES(JFJochIndexing PRIVATE
|
|
CUDAMemHelpers.h
|
|
FFTIndexerGPU.cu FFTIndexerGPU.h
|
|
FFBIDXIndexer.cpp FFBIDXIndexer.h)
|
|
# The two shipped products (jfjoch_viewer, rugnux) link cuFFT STATICALLY on every platform.
|
|
# It is the only CUDA component that was ever dynamic -- cudart and the fast-feedback indexer are
|
|
# already static -- and shipping it as a .so meant each self-contained artifact had to carry the
|
|
# library beside its executables and find it again through an $ORIGIN rpath, machinery that
|
|
# silently failed for any executable that was not the one the rpath had been set on. Static, an
|
|
# artifact is one file that runs; it is also what lets rugnux ship as a bare rugnux.exe on
|
|
# Windows. A cross build has no alternative anyway: NVIDIA's cross-linux-sbsa packages carry
|
|
# libcufft_static.a and no libcufft.so at all.
|
|
#
|
|
# The server stack keeps the shared library: its .deb/.rpm take CUDA from the distro, so there is
|
|
# nothing to bundle, and every executable in that build (broker, tests, tools) would otherwise
|
|
# need the device-link step below.
|
|
IF (JFJOCH_PORTABLE_ONLY)
|
|
TARGET_LINK_LIBRARIES(JFJochIndexing fast_indexer_static CUDA::cufft_static)
|
|
ELSE()
|
|
TARGET_LINK_LIBRARIES(JFJochIndexing fast_indexer_static CUDA::cufft)
|
|
ENDIF()
|
|
ELSE()
|
|
MESSAGE(WARNING "CUDA is strongly recommended for image analysis." )
|
|
|
|
TARGET_LINK_LIBRARIES(JFJochIndexing Eigen3::Eigen)
|
|
ENDIF()
|
|
|
|
# FFTW (fftw3f) is always available via FetchContent -> the CPU FFT indexer is always built.
|
|
TARGET_SOURCES(JFJochIndexing PRIVATE FFTIndexerCPU.cpp FFTIndexerCPU.h)
|
|
TARGET_LINK_LIBRARIES(JFJochIndexing fftw3f)
|