Skip to content

fix: try multiple library names when loading HDF5 on Linux#20

Merged
shinaoka merged 1 commit intomainfrom
fix/linux-library-search-paths
Feb 14, 2026
Merged

fix: try multiple library names when loading HDF5 on Linux#20
shinaoka merged 1 commit intomainfrom
fix/linux-library-search-paths

Conversation

@shinaoka
Copy link
Copy Markdown
Member

Summary

  • On Debian/Ubuntu, HDF5 is installed as libhdf5_serial.so, not libhdf5.so
  • The previous code only tried libhdf5.so, causing dlopen to fail on these distributions
  • Now tries multiple candidate names in order before giving up

Changes

  • Refactored init() to use a default_library_candidates() function returning a list of names to try
  • Linux: libhdf5.so, libhdf5_serial.so
  • macOS: /opt/homebrew/lib/libhdf5.dylib, /usr/local/lib/libhdf5.dylib, libhdf5.dylib
  • Error message now reports all attempted names

Context

This fixes a failure in tensor4all-rs CI where cargo test --workspace triggers feature unification, enabling runtime-loading (dlopen path) instead of compile-time linking. On Ubuntu CI runners, libhdf5.so doesn't exist — only libhdf5_serial.so.

🤖 Generated with Claude Code

On Debian/Ubuntu, the HDF5 shared library is named `libhdf5_serial.so`
rather than `libhdf5.so`. The previous code only tried `libhdf5.so`,
causing dlopen to fail on these distributions.

Now tries multiple candidate names in order:
- Linux: `libhdf5.so`, `libhdf5_serial.so`
- macOS: `/opt/homebrew/lib/libhdf5.dylib`, `/usr/local/lib/libhdf5.dylib`, `libhdf5.dylib`

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@shinaoka shinaoka merged commit d12eceb into main Feb 14, 2026
7 checks passed
@shinaoka shinaoka deleted the fix/linux-library-search-paths branch February 14, 2026 12:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant