Hi Martijn, > I understand that it is desirable to protect users from inadvertently using > incompatible versions of the library, but it seems crazy to me that one > change in the release number should break everything - particularly if you > know it's compatible because you've tested it! As an application writer I > should be allowed to implement my own check on the version and decide a > course of action, not have one forced on me (an unexplained abort() at > that!).
With h5py we had a similar issue; PyTables and h5py both ship with a copy of the HDF5 dll and depending on which one was imported first certain functions would break. I don't recall getting an abort(), it was more that the Python loader complained about unresolved symbols. The solution was to rename the DLL we distributed with h5py, so that the Python process actually had two independent versions of HDF5 loaded. If you distribute HDF5 with your application, this is one possible solution, although I'm the first to agree it's a hack. Keep in mind it has to be done within cmake (renaming the output file isn't enough). By the way, thanks for h5labview. We use it in our lab (University of Colorado dust accelerator) and it's working great. Andrew _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
