| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
to account for platform dependent types in dealing with ds_list_t. Added generator program for test files of LE and BE dimension scales.
Tested: local linux, h5committest
|
|
|
|
| |
Tested: h5committest - just smirom
|
|
|
|
|
|
|
|
|
|
| |
Correct compile warnings and rename fiels to match the rest of the
test files in this directory.
Note: this is currently failing for srcdir builds!
Tested on:
FreeBSD/32 6.3 (duty)
|
|
|
|
|
|
|
|
| |
platform dependent types. Added test and test files for LE and BE dimension scales. Reworked part of test_ds file as part of debug.
Added missing H5Tclose in region reference routines.
Tested: local linux, smirom, linew
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merge from trunk
Description:
Merged revisions 17228 and 17440 from trunk to 1.8
Specifically, this brings support of --enable-static-exec flag into 1.8
Tested:
Manually on jam, linew, smirom, liberty, plus h5committest.
Currently, there is no automatic regression test that exists due to
portability issues. Behavior is both different and undefined on certain
systems (and while 'nm' command seems to exist on all machines, behavior
is confirmed to be different on Mac, possibly others). Solution will be
to set up some sort of framework in daily tests to build statically,
remove shared paths, and verify executables can function.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updating autotools
Description:
Bring revisions 17345 and 17357 from trunk to 1.8, specifically:
- Automake upgraded to 1.11
- Autoconf upgraded to 2.64
- bin/reconfigure script edited to use new versions (on jam), and
run to generate new configure script and Makefile.in's.
- configure.in script edited to add "_cv_" to all AC_CACHE_VAL strings
(in order to comply with new autoconf standard).
- bin/install-sh script replaced with new version as provided
by automake.
Tested:
- All issues on trunk were resolved, so only tested on jam and linew. Any
other outliers should be caught by daily tests.
|
|
|
|
|
|
|
|
|
| |
Clean up various compiler warnings from IRIX64 build
Tested on:
Mac OS X/32 (amazon) debug & production
(yes, I know it's not an IRIX64 system :-)
Too minor to require h5committest
|
|
|
|
|
|
| |
Removed extra space after !DEC$ to satisfy absoft compiler.
tested: smirom
|
| |
|
|
|
|
|
|
|
|
|
| |
#1522 (B1) h5ltread_dataset_string_f error with g95
ISSUE: h5ltread_dataset_string_f causes library assertion with g95.
SOLUTION: convert the fortran string buffer to a C buffer with HD5f2cstring, and pass this string to the C function
TEST: added a test call in the fortran test lite program
DOCS: added the note in RELEASE.txt "- Lite: the h5ltread_dataset_string_f and h5ltget_attribute_string_f functions had memory problems with the g95 fortran compiler. (PVN - 5/13/2009) 1522
tested: linux g95, windows fortran intel 11
|
|
|
|
|
| |
bug fix. call free on a string allocated by HD5f2cstring
tested: linux, windows
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merge these trunk revisions which occurred during the 1.8.3 release code
freeze back to the 1.8 branch:
From Quincey: 16845 16847 16849 16851 16858 16869 16897
From Ray: 16859 16880
From Allen: 16863
Tested on:
FreeBSD/32 6.3 (duty) in debug mode
FreeBSD/64 6.3 (liberty) w/C++ & FORTRAN, in debug mode
Linux/32 2.6 (jam) w/PGI compilers, w/C++ & FORTRAN, w/threadsafe,
in debug mode
Linux/64-amd64 2.6 (smirom) w/Intel compilers w/default API=1.6.x,
w/C++ & FORTRAN, in production mode
Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
w/szip filter, in production mode
Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN,
in production mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in debug mode
Linux/64-amd64 2.6 (abe) w/parallel, w/FORTRAN, in production mode
Mac OS X/32 10.5.6 (amazon) in debug mode
Mac OS X/32 10.5.6 (amazon) w/C++ & FORTRAN, w/threadsafe,
in production mode
|
|
|
|
|
|
| |
tar ball
for remote testing.
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Updated bin/reconfigure to use latest version of automake (1.10.2).
Regenerated Makefile.in's by running bin/reconfigure.
- Added libtool version numbers to c++, fortran, hl, hl c++, and hl fortran
libraries.
Tested:
jam, liberty, smirom
|
|
|
|
|
| |
clean linux warnings
tested linux
|
|
|
|
|
| |
clean warnings linux
tested linux
|
|
|
|
|
| |
added some print messages
tested: linux
|
|
|
|
|
|
|
|
| |
#1538 (B2) Problems with Dim Scale APIs reported by Mathworks
ISSUE2: the scale index input/output parameter value passed to H5DSiterate_scales was not always incremented (it returns the scale index current iteration).
SOLUTION FOR ISSUE2: modified the cycle in H5DSiterate_scales so that the scale index is always incremented
TEST: added some test cases with calls to invalid indices and H5DSiterate_scales with return scale indices and visitor data
tested: linux
|
|
|
|
|
|
|
|
|
|
| |
#1538 (B2) Problems with Dim Scale APIs reported by Mathworks
ISSUE: When some functions are called with an invalid dimension index (for example, greater than the rank of the dataset) the function does not immediately fail, rather asserts down the code.
SOLUTION: added this check for H5DSdetach_scale, H5DSset_label, H5DSget_label (the other functions have this check) . H5DSiterate_scales also added a check for an invalid dimension scale index
TEST: added some test cases with calls to invalid indices
DOCS: Nothing added
STATUS: done for 1.9, 1.8. closed bug
tested: windows, linux
|
|
|
|
|
|
|
|
| |
#1521 (B2) H5DSdetach_scale memory leak
ISSUE: Purify (Windows Visual Studio 6) complains of a memory leak in H5DSdetach_scale call regarding a H5Aread call (stack is H5A_read, H5T_convert, H5T_conv_vlen, H5T_vlen_seq_mem_write, H5MM_malloc).
SOLUTION: When a scale is detached from a dataset, the variable length structure length field is decreased in one entry. The associated pointer must be reallocated with the new length.
DOCS AND TEST: Nothing added
tested: linux
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
#1047 (B1) The h5lt info routines are returning data in transposed form. ISSUE : the dimension array of the function h5ltget_dataset_info_f was not transposed (because of C-FORTRAN storage order, the FORTRAN function calls the C function with the same name). SOLUTION: transpose the array. ACTION: add a test case.
added the note
Fortran High-Level APIs:
------
- Lite: The h5ltget_dataset_info_f function (gets information about a dataset)
was not correctly returning the dimension array (PVN - 2009/3/23)
tested: linux
|
|
|
|
|
|
| |
1. #1487 (B1) DS memory leaks ISSUE 1: On a "go to" error condition, previously allocated buffers were not freed. NOTE: these are "potential" memory leaks because typically the error conditions do not occur, so the potential memory leaks also do NOT occur. ISSUE 2: A function used to read dimension scales realistic data (topography of the North Atlantic, latitude and longitude) was being called without the data buffer being freed. SOLUTION FOR ISSUE 1: added "free" calls for the allocated buffers on the error sections. SOLUTION FOR ISSUE 2: added a "free" call after the read_data function, after using the buffer (on a H5Dwrite and H5Screate_simple). The read_data function reads both data and dimensions from the ASCII data files. DOCS: no docs added. Done for 1.9 and 1.8 STATUS: Closed bug
tested: h5committest
|
|
|
|
|
|
|
|
| |
Bring r16560 back from trunk.
Tested on:
Mac OS X/32 10.5.6 (amazon) debug & production
(Following up with tests on more platforms)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Fix
Description:
Fixing BZ #1381. The --includedir=DIR configure option, which is used to
spceify installation location of C header files, did not work correctly as
the path was hard-coded into config/commence.am. I'm presuming this is
because an older version of automake didn't know where to put C header
files. In any case, removing this line now defaults the includedir to the
same directory that it is currently hard-coded to, and also fixes the
configure flag which allows for customization of this value.
Tested:
jam, liberty
|
|
|
|
|
|
|
|
|
| |
string ptr's belonging to buffer in H5DSset_label and H5DSget_label. Also added free of buffers in error section of both functions. Potential memory leaks may exist elsewhere, and this will not close the bug.
Tested:
h5committest
vista 32 VS2008
|
|
|
|
|
|
| |
have 2 expected outputs for 2 h5ls runs depending if run on a big or little endian machine. Configure.in was modified to export a variable carrying endianess information to testh5ls.sh. This script then compares the current run with 2 expected outputs, one for a big-endian machine (linew was used to generate the output), other for little endian (jam was used to generate the output)
the way h5ls prints types, it starts searching for NATIVE types first. One solution would be h5ls not to detect these native types, using for example the same print datatype function that h5dump does, that would make the output look the same on all platforms ("32-bit little-endian integer" would be printed instead). Drawback, this "native" information would not be available. Other solution is to have not one but 2 expected outputs and make the shell script detect the endianess and compare with one output or other
tested: jam, linew
|
|
|
|
|
|
|
|
|
| |
replacing all instances with long long.
Tested:
h5comittest
fedora 10 x64
XP32, VNET
|
|
|
|
|
|
| |
Changed 'THG' to 'The HDF Group' in various HDF5 source files,
most of which are <subdirectory>/COPYING.
-- Closes Bugzilla entry 1403.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
16132
some chunks were not deleted for some cases, the comparison to check for chunk offsets outside of the new dimensions was
chunk_offset[ i ] > dimension [ i ]
and it must be
chunk_offset[ i ] >= dimension [ i ]
16133
H5TBdelete_record was not handlong correctly records at the end of the table
added a ckeck that avoids to read these records if they are not needed (for pushing down the table)
16143
add a test for recent fixes of H5Dset_extent
tested: windows, linux
|
|
|
|
| |
tested windows linux
|
|
|
|
| |
tested: windows, linux
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description: Libtool wasn't working on linew because the script was
not working with the Solaris Bourne shell. Libtool has built-
in detection to ensure that it uses an appropriate shell,
but our config/commence.am was hard coding this shell to be
/bin/sh. Removing this line allows the shell to be picked up
by configure, thus allowing libtool to use the correct shell
on linew (bash). This was initially added to correct for a problem
on an old machine (janus), so shoudn't be needed for machines
we currently support.
Tested: full make check install on kagiso and linew, compile only
on smirom, duty, and liberty.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description:
1) configure now sets LD_LIBRARY_PATH before checking for presence of
SZIP encoder, so user does not need to set this. The path is then
saved and sent to Makefiles, and used when "make check-install" is
invoked, so user doesn't need to set this manually.
2) Upgraded libtool to version 2.2.6a
3) Rearranged tools build order as h5dump depends on existence of h5diff
and h5import. Since h5dump is a sister directory as opposed to a parent
of either, it doesn't know about the build rules of these tools, so
setting any sort of explicit dependency confuses automake as it won't
know how to build the tools. Instead, setting CONFIG = ordered forces
an in-order traversal of each tools subdirectory. (without it will also
traverse in order by default, but this should prevent gmake's -j option
from jumping ahead as well). 'make check install' should now be able to
be invoked after 'configure' without causing a dependency failure.
4) Removed H5_HAVE_LARGE_HSIZET macro from vms/src/h5pubconf.h, as this macro
has now been out of the code for some time. (vms pubconf needs to be
updated manually, which is why it was still hanging around).
Tested: kagiso, smirom, liberty
Note: h5diff looks to be causing failures in h5copy and h5dump tools tests,
though these were present before any of my changes. My changes only
affect build order and configuration setup, and shouldn't prevent
fixes for these failures coming in after this checkin. Other than these,
tests pass fine.
|
|
|
|
|
|
|
|
|
|
|
| |
The custom rules for installing h5cc, h5fc, and the fortran modules in fortran
and in hl/fortran don't use $(DESTDIR). Added it to all those rules.
Tested: kagiso both serial and parallel with fortran and cxx enabled.
Tested by:
make install
make DESTDIR=/tmp/acheng install
diff -r /tmp/acheng/.../hdf5 hdf5
|
|
|
|
|
|
| |
A space id was not closed in H5PTopen
Tested: windows, linux
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove trailing whitespace from C/C++ source files, with the following
script:
foreach f (*.[ch] *.cpp)
sed 's/[[:blank:]]*$//' $f > sed.out && mv sed.out $f
end
Tested on:
Mac OS X/32 10.5.5 (amazon)
No need for h5committest, just whitespace changes...
|
|
|
|
|
|
|
|
| |
Bring revision 15462 (compiler warnings) back from trunk.
Tested on:
Mac OS X/32 10.5.4 (amazon) w/FORTRAN & C++
(Too minor to require h5committest)
|
|
|
|
|
|
|
|
|
|
| |
Description:
As part of our Windows cleanup, we try to remove windows-specific tweaks in the source code. There are many instances where Windows code is introduces via ifdef's. We re-evaluate whether they are still required, and found that many of them are not. Others we change to "feature"-specific code, rather than Windows-specific.
Tested:
VS2005 on WinXP
VS.NET on WinXP
h5committest (kagisopp, smirom, linew)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description:
The fortran Makefile.am used HDF_FORTRAN to indicate it is part of the
Fortran API source so that conclude.am will give fortran api prefix in the
test output. The symbox HDF_FORTRAN is also used in configure for a different
purpose (indicated --enable-fortran). They conflicted.
Similar problem for the symbol HDF_CXX.
Solution:
Changed all the involved Makefile.am to use "FORTRAN_API" instead. It is
a more appropriate name. Same for CXX_API.
Along the way, discovered that the Makefile.am of hl/fortran/test and
hl/cxx/test did not have those symbols at all. Added them in.
Platform tested:
Kagiso serial and h5committested (kagisopp, smirom, linew).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improvement.
Description:
src/libhdf5.settings was the initial configure summary and is installed.
Then configure is changed to dump a summary of the configure settings to
the output and also append it to src/libhdf5.settings. That created
two different output formats and duplicated information. This is the
initial attempt to clean up this confusion and unify the output format.
It is decided to use the src/libhdf5.settings template as the unified means.
This requires more macros symbols be defined. The following symbols are
all related to generating the src/libhdf5.settings file.
AC_SUBST(EXTERNAL_FILTERS)
AC_SUBST(MPE) MPE=no
AC_SUBST(STATIC_EXEC) STATIC_EXEC=no
AC_SUBST(HDF_FORTRAN) HDF_FORTRAN=no
AC_SUBST(FC) HDF_FORTRAN=no
AC_SUBST(HDF_CXX) HDF_CXX=no
AC_SUBST(CXX) HDF_CXX=no
AC_SUBST(HDF5_HL) HDF5_HL=yes
AC_SUBST(GPFS) GPFS=no
AC_SUBST(LINUX_LFS) LINUX_LFS=no
AC_SUBST(INSTRUMENT) INSTRUMENT=no
AC_SUBST(CODESTACK) CODESTACK=no
AC_SUBST(HAVE_DMALLOC) HAVE_DMALLOC=no
AC_SUBST(DIRECT_VFD) DIRECT_VFD=no
AC_SUBST(THREADSAFE) THREADSAFE=no
AC_SUBST(STATIC_SHARED)
AC_SUBST(enable_shared)
AC_SUBST(enable_static)
AC_SUBST(UNAME_INFO) UNAME_INFO=`uname -a`
The src/libhdf5.settings.in has CONDITIONAL's added to it too. The
untrue conditions turned into a "#" and these lines are cleaned by the
post processing script.
Platform tested:
h5committest on kagiso, smirom and linew. (smirom had failures not due to
my changes.)
|
|
|
|
|
|
|
|
|
|
|
| |
Purpose: Configure Fix
Description: The test program h52gifgentst was getting installed in the bin
directory during 'make install', and it shouldn't. Make now builds
the program for use in testing but doesn't install it during
'make install'.
Tested: kagiso
|
|
|
|
|
|
|
| |
Description: cleaning up configure related to removal of --disable-hsizet
flag, which we no longer support.
Tested: kagiso
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libtool 2.2
Description: Updated bin/reconfigure script to reflect the new versions of
libtool and automake in the /home1/packages/ directory.
Rearranged configure.in script. For some reason, when using
libtool 2.2, the libtool script doesn't generate until
later in the configuration process, so I had to move
a test that parsed through the libtool script to a point
after where it was actually being generated.
Ran libtoolize on the project, and ran bin/reconfigure to
regenerate configure and Makefile.in's throughout.
Tested: kagiso, smirom, linew, tg-login
|
|
|
|
|
|
| |
branch code freeze. No changes
are allowed until official announcement.
|
|
|
|
|
|
|
| |
this function was done in 2002 but was at a time (2003-2006) previewed not to be used
it is now being used again
tested: windows, linux
|
|
|
|
|
| |
not tested, since /examples has several compiling errors due to new APIs
this check in should have no problems
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add work-around to allow reading files that were produced with a buggy
earlier version of the library, which could create objects with the wrong
object header message count. There is now a configure flag
"--enable-strict-format-checks" which triggers a failure on reading a file
with this sort of corruption (when enabled) and allows the object to be read
(when disabled). The default value for the "strict-format-checks" flag is
yes when the "debug" flag is enabled and no when the "debug" flag is disabled.
Note that if strict format checks are disabled (allowing objects with
this particular kind of corruption to be read) and the file is opened with
write access, the library will re-write the object header for the corrupt
object with the correct # of object header messages.
This closes bugzilla bug #1010.
Tested on:
FreeBSD/32 6.2 (duty) in debug mode
FreeBSD/64 6.2 (liberty) w/C++ & FORTRAN, in debug mode
Linux/32 2.6 (kagiso) w/PGI compilers, w/C++ & FORTRAN, w/threadsafe,
in debug mode
Linux/64-amd64 2.6 (smirom) w/default API=1.6.x, w/C++ & FORTRAN,
in production mode
Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN,
in production mode
Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
w/szip filter, in production mode
Mac OS X/32 10.4.10 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
|
|
|
|
|
|
| |
dataset
tested: windows, linux solaris w/fortran
|
|
|
|
| |
tested: linux
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change H5Oget_info -> H5Oget_info_by_name and re-add H5Oget_info in a
simpler form for querying a particular object, to align with other new API
routines.
Tested on:
FreeBSD/32 6.2 (duty) in debug mode
FreeBSD/64 6.2 (liberty) w/C++ & FORTRAN, in debug mode
Linux/32 2.6 (kagiso) w/PGI compilers, w/C++ & FORTRAN, w/threadsafe,
in debug mode
Linux/64-amd64 2.6 (smirom) w/default API=1.6.x, w/C++ & FORTRAN,
in production mode
Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN,
in production mode
Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
w/szip filter, in production mode
Mac OS X/32 10.4.10 (amazon) in debug mode
|