The version of libtool used by HDF5 isn't directly affected by the reconfigure
script; instead, libtoolize --force must be used by hand. Libtool was the
source of the problem, so rolling its version back to 1.5.14 should solve the
issue (at least temporarily).
Reconfigure should still work on both heping and kagiso.
Tested on heping, kagiso, and tg-login3.
Add support for "delete by index" to "old-style" groups, finishing
implmentation of H5Ldelete_by_idx() routine.
Tested on:
FreeBSD/32 4.11 (sleipnir)
Linux/32 2.4 (heping)
Linux/64 2.4 (mir)
Aix/32 5.? (copper)
More progress toward getting H5Ldelete_by_idx() working - removals on
densely stored links should work now (still needs some more tests). Still
need to write code for removals on "old-style" groups.
Tested on:
FreeBSD/32 4.11 (sleipnir)
h5repack revision:
1. added a new test due to the introduction of H5Ocopy in the copy of objects (compressed dataset with references, that still must go a second sweep of the file to be regenerated).
2. Moved all the source files from the h5repack test program to a new file h5repacktst.c and removed the old ones (testh5repack*.c).
3. Renamed the binary files from test*.h5 to h5repack*.h5 for easy reference.
4. Modified the shell script to use variables for file names instead of hard coded names
More progress toward getting H5Ldelete_by_idx to work fully - can now
delete by index in compact group (but not dense groups or "old-style" groups
yet). Need to go write a v2 B-tree routine to delete from the B-tree by index
before the dense storage will work properly...
Tested on:
Linux/32 2.6 (chicago)
Linux/64 2.6 (chicago2)
Finish refactoring internal link deletion code, to make it possible to
wrap up the H5Ldelete_by_idx() coding.
Tested on:
Linxu/32 2.6 (chicago)
Linxu/64 2.6 (chicago2)
Straighten out some convoluted code when links were being deleted, which
could cause the "delete" callback for user-defined links to not get called when
the group they were in was deleted.
Had to compromise on the "delete" callback though - only calls the callback
with the ID for the file the link is in, instead of the group, since the group
is being held open upstream in the calling sequence during a group deletion and
this prevents a group and its ID from being created. (This could possibly be
worked around, but would cause a fair bit of havoc in the code and I'm not
entirely certain it's worth it...)
Tested on:
Linux/32 2.6 (chicago)
This feature is still in progress; Shared Object Header Messages are not
complete as a feature and are not thoroughly tested. There are still
"TODO" comments in the code (comments with the word "JAMES" in them,
so as not to be confused with other TODO comments).
Hopefully this checkin will reduce the liklihood of conflicts as I finish
implementing this feature.
All current tests pass on juniper, copper (parallel), heping, kagiso, and mir.
Added new example for datasets regions; it uses two new functions
H5Iget_name and H5Rget_name to get name of the dataset the region refernce points to.
Platforms tested:
heping
Move compact storage routines into separate file, to make room for internal
routines that operate on links within group operations.
Tested on:
Linux/32 2.6 (chicago)
Add new H5Lget_val_by_idx() routine & tests.
Also includes most of changes for H5Ldelete_by_idx() routine.
Tested on:
Mac OS X/32 10.4.8 (amazon)
FreeBSD/32 4.11 (sleipnir)
Linux/32 2.4 (heping)
Linux/64 2.4 (mir)
AIX/32 5.? (copper)
Finished implementation of H5Lget_info_by_idx for all cases: old vs. new
group formats, compact vs. dense new link storage, increasing vs. decreasing
vs. native iteration order.
Also, refactor symbol table "foo by index" routines to be more generic
and share more code by using a single B-tree iteration callback which makes
callbacks to a specific "get <foo>" callback.
Tested on:
Mac OS X/32 10.4.8 (amazon)
FreeBSD/32 4.11 (sleipnir)
Linux/32 2.4 (heping)
Linux/64 2.4 (mir)
AIX/32 5.? (copper)
Introduced the second sweep of the file for a case a reference is present and H5Ocopy was not used.
Moved the code from file h5repack_refs.c to h5repack_copy.c and removed the first file
Should disable linking against shared libraries in Fortran for compilers that
don't support shared libraries.
Should also fix problem when the wrong Fortran file extension was specified.
If these changes don't solve the Daily Test issues, I'll look at backing out
the autotool version change until I have time to fix them.
Tested on heping, kagiso, juniper.
It seems that the latest version of libtool is linking against shared versions
of the szip libraries in Fortran, rather than the static versions. ifort
doesn't support shared libraries at all.
To solve the problem, we avoid shared libraries entirely unless we're
building shared Fortran libraries ourselves.
If libtool always behaves like this now, it may cause similar problems on
other machines. If you notice that a machine is breaking when it links against
a shared library, let me know.
Tested on kagiso; nothing new is broken. If Albert has time this afternoon
I'll ask him to test on tg-login3 as well.
h5repack support for H5Ocopy in the copy of objects. The old method
for recreating references was dropped (references recreated in a second
traversal of the file)
The logic for using H5Ocopy or not is
if the input DCPL has filters or non default layout OR these are
requested by the user THEN
use the old h5repack read / write
ELSE
use H5Ocopy
h5dump bug 701. Symptom: The creation of a hardlink pointing to the root group "/" causes h5dump to display it as a link pointing to itself.
Cure: the root group was not being inserted in the table that keeps track of object names and links.
Added a test for this in the test generation program, the creation of a hardlink to the root
Make code that retrieves names for references thrash memory less by keeping
track of the current buffer size and only re-allocating it when necessary.
Tested on:
Linux/64 2.6 (chicago2)
