Hi Mark, Please keep all discussion on list, it is important that the discussion and resolution be documented.
mark.oberfield wrote:
Hello Dr. Gentleman, Thank you for your quick reply. The link you've provided of the most recent build relate to assumptions in the configure script which are not met on the build host. Which is why I tried to give it a shot. I can, and have, worked around those problems to the extent that I was able to understand what was going on. It was only the dyn.load() error that finally caused me to throw up my hands and ask for help.
I am sorry that you have wasted your time on this, and really have no solution to offer you, other than to once again point you to the NetCDF packages. rhdf5 is in disarray (I will still claim that the fact that it fails to build in devel on any platform should be a hint that asking questions first is better, especially if you are going to get annoyed when things don't work) and there is no chance it will get any attention before the next release (hence some time in May). And even then, given the changes to NetCDF I am very tempted to drop it completely in favor of a single interface.
The rhdf5 package is only in BioC devel, not in release, and some minor checking of the build reports would have clearly indicated that it does not currently build. We have not had the resources recently (nor any practical uses) to keep up with HDF5 development. Nor have we completely abandoned the notion that the code might be resurrected, or may be useful to someone who does want to make it work with current releases. I am not sure how you found it, but Googling for rhd5 took me to: http://bioconductor.fhcrc.org/checkResults/2.2/bioc-LATEST/rhdf5/liverpool-buildsrc.html which I hope is sufficiently explicit as to suggest that it is not working.
Sure. But looking at the output there, you and I both know that's due to an assumption in RHDF5's configure script not being met -- it assumes that HDF5 libraries and include files are in /usr/local. An assumption apparently not valid on the build host there. To side-step (workaround) that assumption, revealed another, potential bug, in the R's INSTALL perl script not handling the --configure-args option correctly. Also, RHDF5 configure script (version 1.6.0) does not correctly output the compilation flag for locating HDF5 include directory. Once those are hurdles are overcome, then the two routines hdf_subassign.c and hdf_dataset.c have not kept up with the change to vectorSubscript() routine since version 1.9 with the addition of a new argument to it, "call" . Is there any code changes between version 1.6.0 of RHDF5 and the 1.7.1 version referred in the link you've provided? If so, how can I access it?
You can, but it won't work. You can always pull stuff directly out
of the svn archive, but I just don't think you should. There will be no
end of problems that need to be overcome, many non-trivial. But if you
want to, patches are always welcome. A much simpler approach would be
to update the hdf5 package from CRAN (it has been working much more
recently, and has a much simpler interface to HDF5 so there is less that
would need you to do something).
Again, I am sorry you put effort into this, and we will try to find
some way to be more explicit about the fact that packages in BioC-devel
(and not in BioC release) may be in total disarray.
best wishes
Robert
Thanks! Mark
Robert Gentleman, PhD Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 PO Box 19024 Seattle, Washington 98109-1024 206-667-7700 rgentlem at fhcrc.org