External use of hdf5 not easy to implement, and doesn't work.
Next, I tried turning VTK_MODULE_ENABLE_VTK_hdf5 back on, but then using
This successfully found SPARC's hdf5 library and used that for configure.
But then my build failed. When linking the pvserver executable (and a couple others, like maybe pvdataserver), I got undefined symbol errors. The undefined symbols were like H5Create (or H5PCreate or something), and they were undefined in the library
when I messed around with the nm command, I discovered that the symbols were undefined in the libhdf5_hl.a library, but they were defined in the libhdf5.a library.
When I looked at the link.txt file for pvserver, I saw that both the libhdf5.a and libhdf5_hl.a were in the link line, but libhdf5.a came first. I added libhdf5.a again after libhdf5_hl.a. Then pvserver linked. Clearly if libhdf5 was shared the order wouldn't have mattered. I don't want to add all symbols for libhdf5.a because that might bloat the binary.
What we need here is a successful compile ordering of the static hdf5 libraries in the link.txt file. Also, it would probably help to be able to specify using system hdf5 libraries up at the superbuild cmake level as well.
Getting either #19564 (closed) or this bug fixed is a crisis. We can take either, depending on which is easier, but would prefer getting #19564 (closed) fixed first. Setting milestone and labels appropriately.