I noted from the archives that this was reported in 2011 referring to 1.8.4! A developer named Ian replied with some embarrassment that he had done it. He said it would be fixed in 1.8.7. But, it seems it was not.
When trying to bind to the dynlibs from either h5py or pytables (aka “tables”) I get this error in trying to find the image of the dynlib: Library not loaded: /mnt/scr1/release-binary/hdf5/v187/builds/fred/lib/libhdf5.7.dylib This time “Fred” is the culprit, although I note that one of your builds seems to be nicknamed ‘fred’ or perhaps Fred is the maintainer. This is further confirmed by noting that in the file libhdf5.settings the following appears: Configured by: [email protected] and: Uname information: Darwin fred.hdfgroup.uiuc.edu 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 And the truly offensive part that breaks every attempt to use the library: Installation point: /mnt/scr1/release-binary/hdf5/v187/builds/fred I know you want me to compile it myself and with homebrew that “occasionally” works. But, you are the developers of hdf5. I am not. The library is extensive and complicated. It should not fall to me to debug it. I am attempting to create an install script to simplify the process of creating a “scientific” build of Python, similar to the very nice WinPython, for Mac. In so doing, I wish to minimize dependencies for users. Brew is simple enough, but users who are primarily analysts and Python programmers may not have full Xcode with the clt. HDF5 is my last stumbling block. Everything else builds reliably with pip or easy_install (of course, reliant on gcc—but not all of Xcode) or provides a robust binary distribution. If you think this is an unreasonable goal, as well you may, then I will simply abandon hdf5, pytables, and h5py. Users/developers desirous of obtaining these and the hdf5 libraries will “man up” and build them all themselves. Of course, they may obtain them from Continuum, Enthought, or ActiveState. While folks at these companies are fine and well-qualified people (for sure!) and each provides a community edition, there are always non-standard, proprietary, or simply out-of-date inclusions among their packages. This is fine; they have other things to do that are also valuable to users/customers. It seems that it should not be necessary to create another quasi-commercial packaging of open source components with another package manager and another distribution point. My simple goal is merely to access the various packages and dependencies directly from their original authors’ sites and to install everything in the most vanilla way possible. This has worked for everything but hdf5 (except for requiring brew and building it—or extending the script to build directly with Xcode from one of hdf5’s tar distributions). Your binary distribution would make this quite easy, but far the hard-coded installation point. As the earlier forum post suggested, this could at least be a generic path referring to no user such as usr/local (an excellent choice!) or might be something left in an editable .h file. I will try to edit the above, but I fear this may carry through into binary files that I cannot edit. Your help would be appreciated. I hope this is consistent with your own goals for providing the binary distributions.
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
