Static build with bundled HDF5 2.x fails on RHEL-family systems: sources install to `lib64`, `hdf5-sys` links against `lib`

[rob-p]

Summary

With the static feature and the bundled HDF5 2.2.0 sources, linking fails on a RHEL 8 host:

error: could not find native static library `hdf5`, perhaps an -L flag is missing?
error: could not compile `hdf5-metno-sys` (lib)

The library is built correctly — it just is not where hdf5-sys looks for it:

$ ls target/debug/build/hdf5-metno-src-*/out
bin  build  include  lib64  share

$ ls target/debug/build/hdf5-metno-src-*/out/lib64
cmake  libhdf5.a  libhdf5.settings  pkgconfig

hdf5-sys/build.rs hardcodes lib:

https://github.com/metno/hdf5-rust/blob/10e8bb9/hdf5-sys/build.rs#L789

println!("cargo::rustc-link-search=native={}/lib", hdf5_root);

The same tree with the older bundled sources (hdf5-metno-src 0.10.2, HDF5 1.x) installs to out/lib/ and links fine, so this appears to be a change in HDF5's own CMake install layout between 1.x and 2.x rather than anything in this repo. It presumably does not reproduce on Debian/Ubuntu, where GNUInstallDirs resolves CMAKE_INSTALL_LIBDIR to lib, which would explain why CI has not caught it.

Reproducer

On a distribution where CMake's GNUInstallDirs defaults to lib64 (RHEL / Rocky / Alma / Fedora, 64-bit):

[dependencies]
hdf5-metno-sys = { version = "0.12.2", features = ["static"] }

cargo build   # could not find native static library `hdf5`

Possible fixes

1. Have hdf5-src export the directory it actually installed to. It already emits root, include and library metadata:
   https://github.com/metno/hdf5-rust/blob/10e8bb9/hdf5-src/build.rs#L116-L123
   Adding println!("cargo::metadata=libdir={}", ...) and consuming DEP_HDF5SRC_LIBDIR in hdf5-sys would make this robust to any future layout change.
2. Pin the layout in hdf5-src with cfg.define("CMAKE_INSTALL_LIBDIR", "lib"), so the install directory always matches what hdf5-sys expects. One line, and it keeps the two crates in agreement by construction.
3. Emit both search paths from hdf5-sys ({root}/lib and {root}/lib64). Simplest, though it papers over the mismatch rather than fixing it.

I would lean toward 2 (smallest and self-consistent) or 1 (most robust).

This is distinct from #93, which is about locating a system HDF5 without pkg-config; this one is purely the bundled/static path.

Happy to send a PR if you have a preference.

Environment

• rustc 1.97.1, x86_64-unknown-linux-gnu, RHEL 8
• cmake 3.29.2
• hdf5-metno-sys 0.12.2 with hdf5-metno-src 0.10.3 (HDF5 2.2.0)
• Works with hdf5-metno-src 0.10.2 (HDF5 1.x), which installs to out/lib

[mulimoen]

A PR for option 2 would be much appreciated!

[rob-p]

Verified #205 on the environment that produced this report (RHEL 8, x86_64, cmake 3.31):

• main with the fix: bundled install lands in out/lib, and cargo build -p hdf5-metno-sys --features static links cleanly.
• Negative control (define reverted locally): out/lib64 returns, with the exact could not find native static library \hdf5`` failure.

And hdf5-metno-src 0.10.4 from crates.io resolves the fix for downstream users — nothing else needed. Thanks for turning it around so quickly!

One observation for anyone who can't reproduce the original report: the lib64 behaviour appears to depend on the CMake version, not just the distribution. On the same RHEL 8 host, the unpatched tree installed to lib under cmake 4.4.2, while 3.29/3.31 produce lib64. So pinning CMAKE_INSTALL_LIBDIR (rather than consuming the emitted libdir) was the right call — it's robust to CMake's heuristic moving in either direction.