# Build static libhdf5.a with bundled plugins - possible? **URL:** \ **Category:** HDF5 Library\ **Created:** [January 8, 2026, 6:16pm UTC](https://forum.hdfgroup.org/t/build-static-libhdf5-a-with-bundled-plugins-possible/13640 "2026-01-08T18:16:36Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![philipp.middendorf](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/p/b77776/32.png) [@philipp.middendorf](https://forum.hdfgroup.org/u/philipp.middendorf)\ **Post date:** [January 8, 2026, 6:16pm UTC](https://forum.hdfgroup.org/t/build-static-libhdf5-a-with-bundled-plugins-possible/13640/1 "2026-01-08T18:16:36Z")
I’d like to build `libhdf5.a`, but include a few plugins, such as the bitshuffle filter, so you don’t need to dynamically load these plugins (which is a hassle since it mixes static/dynamic linking). Is this possible? You would have to combine both codebases, but it’s both C, so in theory I don’t see any major hurdles. But I wouldn’t know where to register the plugin so it’s there from the start. ---
**Author:** ![ajelenak](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/a/3d9bf3/32.png) [@ajelenak](https://forum.hdfgroup.org/u/ajelenak)\ **Post date:** [January 14, 2026, 3:27am UTC](https://forum.hdfgroup.org/t/build-static-libhdf5-a-with-bundled-plugins-possible/13640/3 "2026-01-14T03:27:58Z")
It is likely doable, but HDF Group has not really explored this build configuration so there’s nothing to start from. > I wouldn’t know where to register the plugin Can you clarify what you mean? What plugin? ---
**Author:** ![philipp.middendorf](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/p/b77776/32.png) [@philipp.middendorf](https://forum.hdfgroup.org/u/philipp.middendorf)\ **Post date:** [January 15, 2026, 1:30pm UTC](https://forum.hdfgroup.org/t/build-static-libhdf5-a-with-bundled-plugins-possible/13640/4 "2026-01-15T13:30:17Z")
Not sure about the nomenclature here, but from what I gathered, in order to have your HDF5 data be “processed” with your own code, you write the processing code and then make the HDF5 library aware of it, also assigning it an ID. With regular dynamically loaded plugins, this happens during discovery of the .dll/.so file. But I would have to do this more directly. ---
**Author:** ![gheber](https://forum.hdfgroup.org/user_avatar/forum.hdfgroup.org/gheber/32/1919_2.png) [@gheber](https://forum.hdfgroup.org/u/gheber)\ **Post date:** [January 15, 2026, 1:39pm UTC](https://forum.hdfgroup.org/t/build-static-libhdf5-a-with-bundled-plugins-possible/13640/5 "2026-01-15T13:39:55Z")
Check out [HDF5 Filter Plugins](https://support.hdfgroup.org/documentation/hdf5/latest/_h5_p_l__u_g.html#sec_filter_plugins). Skip the plugin part for the dynamic loading portion. Just call `H5Z[un]register` in your application, and you should be fine. OK? G. ---
**Author:** ![bmribler](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/b/a6a055/32.png) [@bmribler](https://forum.hdfgroup.org/u/bmribler)\ **Post date:** [January 15, 2026, 3:37pm UTC](https://forum.hdfgroup.org/t/build-static-libhdf5-a-with-bundled-plugins-possible/13640/6 "2026-01-15T15:37:13Z")
If I understand you correctly, you can register a plugin by following the instruction on the [Registered HDF5 Filter Plugins](https://github.com/HDFGroup/hdf5_plugins/blob/master/docs/RegisteredFilterPlugins.md "https://github.com/HDFGroup/hdf5\_plugins/blob/master/docs/RegisteredFilterPlugins.md") page. ---
**Author:** ![philipp.middendorf](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/p/b77776/32.png) [@philipp.middendorf](https://forum.hdfgroup.org/u/philipp.middendorf)\ **Post date:** [January 16, 2026, 7:00am UTC](https://forum.hdfgroup.org/t/build-static-libhdf5-a-with-bundled-plugins-possible/13640/7 "2026-01-16T07:00:49Z")
We are on the right track here, but it’s still missing the point. @gheber, you’re saying I should register the plugin in the _application_. I would like to have the plugin “pre-registered” in the _library_ somehow, so that I can just use it in my applications and not worry about forgetting to register something, or setting a `HDF5_PLUGIN_PATH` variable or copying `.so` files and whatnot. Just like with certain filters that are built-in to HDF5. At least how I understand it, deflate doesn’t need an external plugin? More understandable now? I’ve tried looking for how deflate is integrated into libhdf5, but I got lost. ---
**Author:** ![gheber](https://forum.hdfgroup.org/user_avatar/forum.hdfgroup.org/gheber/32/1919_2.png) [@gheber](https://forum.hdfgroup.org/u/gheber)\ **Post date:** [January 16, 2026, 11:35am UTC](https://forum.hdfgroup.org/t/build-static-libhdf5-a-with-bundled-plugins-possible/13640/8 "2026-01-16T11:35:01Z")
I thought you had your own filter code, and you just compile and link that all together. I think what you are asking is how to bundle all the pieces together. Right? I don’t think we have a CMake target for that at the moment. But here’s what you can do: ```auto mkdir -p build/merge cd build/merge # throw all the archives and objects you wanna bundle in here ar -x ../libhdf5.a ar -x ../libz.a ar -x ../libmy_lib.a ar -qc liball.a *.o ranlib liball.a ``` `liball.a` is your proverbial kitchensink. OK? G. ---
**Author:** ![philipp.middendorf](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/p/b77776/32.png) [@philipp.middendorf](https://forum.hdfgroup.org/u/philipp.middendorf)\ **Post date:** [January 16, 2026, 12:13pm UTC](https://forum.hdfgroup.org/t/build-static-libhdf5-a-with-bundled-plugins-possible/13640/9 "2026-01-16T12:13:06Z")
Ahhh, just (static) linking to a plugin registers it (because of some initialization happening automatically)? ---
**Author:** ![gheber](https://forum.hdfgroup.org/user_avatar/forum.hdfgroup.org/gheber/32/1919_2.png) [@gheber](https://forum.hdfgroup.org/u/gheber)\ **Post date:** [January 16, 2026, 8:51pm UTC](https://forum.hdfgroup.org/t/build-static-libhdf5-a-with-bundled-plugins-possible/13640/10 "2026-01-16T20:51:13Z")
No, not quite. I think there is a bit of terminological confusion going on here. When the HDF5 library is compiled it contains a minimal set of filters (e.g., N-bit, shuffle, etc.) These filters are “baked into the library.” You can configure the inclusion of additional filters, such a Gzip or SZip compression. However, the binaries for these filters are typically separate from the HDF5 library binary. You would still link your application against `libhdf5.[a,so]` and `libz.[a,so]`, etc. Yes, these, known at compile-time, filters, would be available to you without further initialization on your part. I wouldn’t call them plugins, though. The term ‘plugin’ is usually applied to a shared binary object `*.[so,dll]` that can be loaded dynamically(= at runtime) by an application process. That way you can use a filter with an HDF5 library (provided your execution policy allows the dynamic loading of shared objects) that was build without knowledge of the specifics of that particular filter. All that matters is that it abides by the filter API (i.e., implements the right callbacks, etc.). OK? But, I’m afraid, I’m still not sure I understand what you are trying to achieve. Best, G. ---
**Author:** ![philipp.middendorf](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/p/b77776/32.png) [@philipp.middendorf](https://forum.hdfgroup.org/u/philipp.middendorf)\ **Post date:** [January 19, 2026, 6:41am UTC](https://forum.hdfgroup.org/t/build-static-libhdf5-a-with-bundled-plugins-possible/13640/11 "2026-01-19T06:41:33Z")
Thank you for the clarification! Using this terminology: What I’m trying to achieve is then transforming a plugin (that contains a filter) into a baked-in filter that needs no loading at runtime. ---
**Author:** ![gheber](https://forum.hdfgroup.org/user_avatar/forum.hdfgroup.org/gheber/32/1919_2.png) [@gheber](https://forum.hdfgroup.org/u/gheber)\ **Post date:** [January 20, 2026, 7:08pm UTC](https://forum.hdfgroup.org/t/build-static-libhdf5-a-with-bundled-plugins-possible/13640/12 "2026-01-20T19:08:44Z")
Got it. 1. You will need the source code of the plugin, say, `filter.[c,h]` files. Build a static library (`*.a`) or just an object file (`*.o`). You will need that library or object file to link your application. Optional: Build a catch-all library archive as described earlier (`liball.a`). 2. You will need a filter ID. Scan the list [Registered HDF5 Filter Plugins](https://github.com/HDFGroup/hdf5_plugins/blob/master/docs/RegisteredFilterPlugins.md). If your filter wasn’t registered, consider registering it, or pick an ID in the range `256`-`511`, _for testing only._ (Distributing HDF5 files with filter dependencies in that range is asking for trouble!) 3. Among other things, the `filter.h` header should contain a definition for a `struct H5Z_class_t` or the callbacks that you would use to populate one. Include that header in your application, and call [`H5Zregister`](https://support.hdfgroup.org/documentation/hdf5/latest/group___h5_z.html#ga93145acc38c2c60d832b7a9b0123706b), passing a pointer to your initialized instance of a `struct H5Z_class_t`. (Check the return value to ensure that the registration was successful.) 4. When using the filter with your dataset(s), the library should find your registered filter automatically. When reading/writing an existing dataset, the matching filter ID will be sufficient. When creating a new dataset, you must pass a creation property list with the filter info provided via [`H5Pset_filter`](https://support.hdfgroup.org/documentation/hdf5/latest/group___o_c_p_l.html#gae7ac4c110e9ec3fcf38966928b96cda3). 5. Call [`H5Zunregister`](https://support.hdfgroup.org/documentation/hdf5/latest/group___h5_z.html#ga6b8bcdde70c9256c50c7c62ba66380f8) when the filter is no longer needed in the application and to free the associated resources. OK? G.