NetCDF: Build against HDF5 1.14 #6795
Conversation
eschnett
commented
May 25, 2023
eschnett
commented
- update version_offset
- correct tarball checksum
- correct Windows build instruction
- remove outdated Apple work-around
- build on more platforms
- add new dependencies bzip2 (necessary) and zstd (because we can)
- update version_offset - correct tarball checksum - correct Windows build instruction - remove outdated Apple work-around - build on more platforms - add new dependencies bzip2 (necessary) and zstd (because we can)
|
|
||
| export CPPFLAGS="-I${includedir}" | ||
| export LDFLAGS="-L${libdir}" | ||
| export LDFLAGS_MAKE="${LDFLAGS}" | ||
| CONFIGURE_OPTIONS="" | ||
|
|
||
| if [[ ${target} == *-mingw* ]]; then | ||
| export LIBS="-lhdf5-0 -lhdf5_hl-0 -lcurl-4 -lz" | ||
| # we should determine the dll version (?) automatically |
There was a problem hiding this comment.
Yeah, to be honest I'm a bit worried about those random numbers like 310. Where they come from? Will they change in hdf5 1.15? If so, it'd be ABI-incompatible with v1.14
There was a problem hiding this comment.
I think that's essentially the soversion of the library, produced by HDF5's build system. We can probably, if we want to, modify the Windows build script for HDF5 to change these numbers to 0.
On the other hand, if these numbers indicate binary (ABI) compatibility, then we should probably heed them, and be quite strict about the compat declaration when using HDF5_jll.
There was a problem hiding this comment.
On the other hand, if these numbers indicate binary (ABI) compatibility
Yes, the SONAME is part of the ABI, whenever it changes the ABI changes. If they change the soname for every minor version (sigh) we really must be strict about compat bounds.
|
Interesting I was working on the same here: But I did not jet made a PR, so please feel free to go ahead to make the update. (To be honest, I do know where the XY in -lhdf5-XY come from in mingw.) |
Co-authored-by: Mark Kittisopikul <mkitti@users.noreply.github.com>
