bnprks
BPCells requires hdf5 (>= 1.12.0)
Hello, I'm just sharing this here in case other run into this problem, which is likely if you're on RedHat 8/Rocky 8/Alma 8 Linux.
TL;DR
If you get:
$ R
R version 4.5.2 (2025-10-31) -- "[Not] Part in a Rumble"
...
> remotes::install_github("bnprks/BPCells/r")
...
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘BPCells’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/c4/home/henrik/R/rocky8-x86_64-pc-linux-gnu-library/4.5-CBI-gcc13/00LOCK-BPCells/00new/BPCells/libs/BPCells.so':
/c4/home/henrik/R/rocky8-x86_64-pc-linux-gnu-library/4.5-CBI-gcc13/00LOCK-BPCells/00new/BPCells/libs/BPCells.so: undefined symbol: H5Treclaim
Error: loading failed
you most likely have a too old version of system package 'hdf5' installed. H5Treclaim was introduced in hdf5 1.12.0 (2020-02-28). I can confirm that BPCells builds and installs fine with hdf5 1.12.2 (installed from source from https://github.com/HDFGroup/hdf5/releases).
As a reference, an up-to-date RedHat 8, Rocky 8, ... Linux system comes with hdf5 1.10.5 (e.g. h5stat --version).
Suggestion
To the maintainer of BPCells, please consider adding an assertion for hdf5 (>= 1.12.0) in the configuration step. I see that you've already run a small compilation test:
...
Installing package into ‘/c4/home/henrik/R/rocky8-x86_64-pc-linux-gnu-library/4.5-CBI-gcc13’
(as ‘lib’ is unspecified)
* installing *source* package ‘BPCells’ ...
** this is package ‘BPCells’ version ‘0.3.1’
** using staged installation
Recording install count metrics
Testing hdf5 by compiling example program...
Found working hdf5
HDF5_CFLAGS=''
HDF5_LIBS='-lhdf5'
Testing C++17 filesystem feature support...
Testing availability of highway SIMD library...
Highway not found or unusable
Building highway SIMD library from source
...
Good catch, I definitely encountered this before, without thinking to fix it. I'll do so within next few days
So I've noticed that I can't consistently get version 1.10.5, or version 1.10.10 to fail. Moreover, our CI pipelines actually use v1.10 for hdf5, so I don't think its a blanket statement that BPCells requires hdf5 >= 1.12.0.
Nonetheless, I think this behaviour is strange. In cpp/vendor/highfive/bits, I see the only place H5Treclaim being called is wrapped in an #if H5_VERSION_GE(1, 12, 0) block. This means that it shouldn't be in the the shared object unless during compilation unless you had a version of hdf5 that compiles greater than v1.12, and another version at runtime that can't recognize h5treclaim.
I realized that I addressed this exact same concern here, and I somehow completely forgot about it. Perhaps my memory is starting to deteriorate...