search

aldanor / hdf5-rust

HDF5 for Rust
https://docs.rs/hdf5
Apache License 2.0
310 stars 84 forks source link

Add support for the latest HDF5 release (1.10.5) #33

Closed aldanor closed 5 years ago

aldanor commented 5 years ago

Release notes

Waiting on the homebrew formula to get merged in so I can work on it locally.

SuperFluffy commented 5 years ago

Is there a way to compile a static version of hdf5 into a binary, similar to how openblas-src does it? They do it via the STATIC feature, see here: https://github.com/blas-lapack-rs/openblas-src/blob/master/build.rs

aldanor commented 5 years ago

Is there a way to compile a static version of hdf5 into a binary, similar to how openblas-src does it? They do it via the STATIC feature, see here: https://github.com/blas-lapack-rs/openblas-src/blob/master/build.rs

In theory something like this is possible, although might be quite clunky here since we'd have to support both the pre-built HDF5 from a distribution (which would be the most likely scenario), plus a hand-built one... Just wondering why? HDF5 is typically distributed with static libraries, could that be reused? (unless you're building this for some obscure embedded platform or something like that, in which case you'd probably still build the HDF5 the way you need it outside of Rust's build system?)

One more thing: HDF5 doesn't have a Makefile out of the box; you have to run autoconf (on posix platforms, that is; I've never touched it on anything Windows-like, you probably have to use msvs or something like that). HDF5's autoconf has many HDF5-specific knobs and levers; e.g. the binaries available in major package linux/macos package distributions are typically configured differently.

SuperFluffy commented 5 years ago

I was confused as to which version of hdf5 was supported, and thought I needed 1.8, hence I asked the question in this issue. Turned out I was wrong and it works with the latest release of hdf5 on my system (hdf5 1.10.5, although I now realize that it might not yet be fully supported by hdf5-rust).

Some systems I work on have not been updated in a while and hence might not provide a recent version of hdf5. As is the case for openblas, it might be easier to have hdf5-rust compile everything and link the result, then me building a recent version of hdf5 on the system and then attempt for hdf5-sys to find that one.

aldanor commented 5 years ago

Oh, no - 1.10.4 is fully supported with all the bindings. By “supported” I really mean that - that the bindings exist.

In fact, I think, even this would work: you could build your crate against the earliest HDF5 version you’d like to support and then on the client side it could be any version as long as it’s ABI-compatible, because of the way hdf-sys is built. I think it even works across 1.8-1.10.

Does this help? https://abi-laboratory.pro/?view=timeline&l=hdf5

SuperFluffy commented 5 years ago

Looks like 1.10.5 is fully backward compatible with 1.10.4. So right now, I use 1.10.5, which is what archlinux provides.

Anyway, I haven't run into any issues yet. I just noticed that there were repeated questions about linking to openblas failing with users of ndarray, which is usually fixed/circumvented by linking a static version of openblas and not using the system version.

aldanor commented 5 years ago

I see. I still think if we were to enable static linking we could reuse those static binaries provided in HDF5 distributions as opposed to building it ourselves? (more of a 'use static library to link, not dynamic') Really not looking forward for messing with autoconf in build scripts here. E.g., looking at the archlinux hdf5 dist, of course it supplies the .a's as well.

Let's see if there's any "repeated questions about linking to hdf5" at any point from the users; if that's the case we can look into providing options to pick the (external) static version of library to link to.