Bring r16846 from revise_chunks branch back to trunk:
Fix broken (for how long?) H5_ASSIGN_OVERFLOW macro to actually detect
overflows during assignments, along with several errors it [now] detected.
Cleaned up a fix minor warnings and/or pieces of code also.
Tested on:
FreeBSD/32 6.3 (duty) in debug mode
(h5committest not needed - multi-platform test performed on branch)
Embed the content of libhdf5.settings into the hdf5 executables so that an
"orphaned" executables can display (via the Unix strings command, for example)
the library settings used to build the executables.
This is a prototype implementation. Much improvement is needed.
configure.in:
Added the --disable-embedded-libinfo option to disable this feature.
configure:
src/H5config.h.in:
Generated by autotools like automake.
src/H5detect.c:
Implement insert_libhdf5_settings() to insert the contents of
libhdf5.settings into the library as an extern string variable so that it
is included in all HDF5 executable. Much improvement is needed.
fortran/src/Makefile.in:
Auto-generated by bin/reconfigure. (i.e., I did make any changes to cause
its direct regeneration).
Tested:
Jam serial, using default and --disable-embedded-libinfo, configure options.
Bring r16305 back from revise_chunks branch:
Add detection of C99 "designated initializers" to configure script and
use new H5_HAVE_C99_DESIGNATED_INITIALIZER macro to conditionally compile
default layout variables in src/H5Pdcpl.c
Also, minor code cleanups, etc.
Tested on:
FreeBSD/32 6.3 (duty) in debug mode
(Other platforms tested on branch)
th user's definition of H5_USE_16_API. The H5_USE_16_API_DEFAULT is defined through
configure with the flag --with-default-api-version=v16.
Tested with h5committest.
Fix various problems with a the core & sec2 VFDs.
Improve the h5_get_file_size() routine to handle files created with
VFDs that use multiple files.
Tested on:
Mac OS X/32 10.5.5 (amazon) in debug mode
Mac OS X/32 10.5.5 (amazon) w/C++ & FORTRAN, w/threadsafe,
in production mode
FreeBSD/32 6.3 (duty) in debug mode
FreeBSD/64 6.3 (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/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 production mode
Linux/64-amd64 2.6 (abe) w/parallel, w/FORTRAN, in production mode
Description: Added configure test to see if pointer alignment restrictions are enforced (as in dereferencing an unaligned pointer causes an error). Added code in H5Tvlen.c to avoid dereferencing unaligned pointers, conditionally compiled based on the configure test. Added test case in dtypes.c which would previously cause such machines to fail.
Tested: kagiso, smirom, linew (h5committest); linew64
Description:
In some of the new H5EA* code, many new C99 features are being used. Most of them are portable to all compilers, but the __func__ keyword in particular isn't supported in Visual Studio on Windows. Instead, Windows defines the __FUNCTION__ keyword, which can be used as a direct substitute.
We now check for the __func__ keyword during configure and define the feature flag H5_HAVE_C99_FUNC. There was previously a check for __FUNCTION__, and the feature flags H5_HAVE_FUNCTION. In H5EApkg.h, we check for the presents of each of these in order to see which to use. If neither are avaiable, fail.
Tested:
h5committest (kagiso, smirom, linew)
Description: Applying update to autotools that was applied to 1.8 a couple
of weeks ago to the trunk.
Updated bin/reconfigure script to reflect the new versions of
libtool and automake in the /home1/packages/ directory.
Rearranged configure.in script. When using libtool 2.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 (h5committest)
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
Removed the stream-vfd from the basic library code.
(The stream-vfd source files are not removed yet but the MANIFEST has been
updated to NOT release those stream-vfd source files.)
Platforms tested:
Kagiso and smirom.
Then test the release tar ball in kagiso.
Remove --enable-hdfv1_6 configure flag, now that all dependencies on it
have been removed and new --with-default-api-version=[v16|v18] and
--disable-deprecated-symbols flags have taken its place.
Update types in bin/trace so that bin/reconfigure runs cleanly.
Run bin/reconfigure to regenerate configure script, along with
other associated files, etc.
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
Description: Configure will now detect the presence of the 'siglongjmp' function. If present,
the macro H5_HAVE_SIGLONGJMP will be defined in src/H5pubconf.h.
Tested: kagiso, smirom, linew
Add --enable-deprecated-symbols configure option, to allow users to
remove deprecated public API symbols at configure time.
Add bin/make_vers script to bin/reconfigure actions.
Run bin/reconfigure to regenerate autotool components.
Tested on:
Mac OS X/32 10.4.10 (amazon)
FreeBSD/32 6.2 (duty)
Linux/32 2.6 (kagiso)
2) Removing configuration of c++/src/H5cxx_pubconf.h file.
Reasoning: the additional pubconf file caused compilation complications, this is cleaner.
Tested: kagiso, smirom
Description: added new configuration to generate a pubconf file
in the c++/src directory, H5cxx_pubconf.h. When C++
compiler recognizes 'offsetof', the macro
H5_CXX_HAVE_OFFSETOF is defined in the new
pubconf file.
tested: kagiso, smirom
Description: When the compiler has the __offsetof__ extension, the
H5_HAVE_OFFSETOF macro will be defined. When the compiler
does not have the extension, the macro will remain undefined.
Tested: kagiso
Description: this flag will define the macro H5_DEFAULT_VFD in src/pubconf.h
and set it to be either H5FD_SEC2 or H5FD_STDIO, depending on the
value set with the configuration flag (either sec2 or stdio).
Tested: kagiso, smirom, linew
file size from MPI_File_get_size. Bypass this problem by replacing it with
stat. Add an option --disable-mpi-size in configure to indicate this function
doesn't work properly. Add a test in testpar/t_mpi.c, too. If it returns wrong
file size, print out a warning.
Tested on kagiso (parallel) because already tested the same change to v1.6 on
several platforms (kagiso, cobalt, copper, and sol).
check if fseeko is available. Using it instead of fseek can support
big files because the offset is of type off_t not long int. Also
added the test for STDIO in big.c.
option --enable-direct-vfd/--disable-direct-vfd to enable/disable Direct I/O support. The default
is enabled. There's a small test in test/vfd.c. Another way to test it is to set environment
variable HDF5_DRIVER to "direct" and run "make check" in the test/ directory. There'll be some
further improvement in the following checkin including allowing user to provide memory boundary
value, file block size, and copying buffer size.
and quote its arguments. Also checks for the 'socket' library on
Solaris.
If this patch passes the Daily Tests and makes the user happy, I'll
port it back to the 1.6 branch.
Tested on mir and sol.
File format is not stable, don't keep files produced!
Description:
First stage of checkins modifying the format of groups to support creation
order. Implement "dense" storage for links in groups.
Try to clarify some of the symbols for the H5L API.
Add the H5Pset_latest_format() flag for FAPLs, to choose to use the newest
file format options (including "dense" link storage in groups)
Add the H5Pset_track_creation_order() flag for GCPLs, to enable creation
order tracking in groups (although no index on creation order yet).
Remove --enable-group-revision configure flag, as file format issues are
now handled in a backwardly/forwardly compatible way.
Clean up lots of compiler warnings and other minor formatting issues.
Tested on:
FreeBSD/32 4.11 (sleipnir) w/threadsafe
Linux/32 2.4 (heping) w/FORTRAN & C++
Linux/64 2.4 (mir) w/enable-v1.6 compa
Mac OSX/32 10.4.8 (amazon)
AIX 5.3 (copper) w/parallel & FORTRAN
Use a slightly less efficient method of computing the log2() on SGI IRIX64,
in order to avoid a compiler bug when optimizations are turned on.
Tested on:
SGI IRIX64 6.5 (atlantia)
1) Added trace file support to the metadata cache. This allows capture
of all metadata cache calls in trace files for purposes of optimization
and debuging.
2) Added an expunge entry function. This allows an entry to be deleteded
from the cache without writing it to disk even if it is dirty.
3) Added a function call to resize pinned entries.
4) Added code to deal with entries that are dirty on load. This is
needed in support of a bug fix which can alter object headers on
load to repair files.
5) Added progress reporting code to the "MDC API smoke check" test in
cache_api.c. To enable the progress reporting, set report_progress
to TRUE in mdc_api_call_smoke_check().
Tested with h5committest, and a parallel test on phoenix (dual athelon
linux box).
Description: Mac OS 10.4 on PowerPC chip has some errors to convert (unsigned)
long long to long double. When the bit sequences are 0x003ff..., 0x007fff...,
0x00ffff..., 0x01ffff..., 0x7fffff..., the converted values are twice as big
as they should be.
Solution: Detect the error in configure and disable the compiler conversion
and test case.
Platforms tested: h5committest, Mac OS 10.4, and fuss.
Description: Data conversion from long double to (unsigned) long long
returns some incorrect values on Mac OS 10.4 and SGI IRIX64 6.5. The
conversions start to go wrong when the long double is
20041683600089727.779961 (0x4351ccf385ebc8a0bfcc2a...). If adjusting
the values higher by assigning 0x...c8a0cf... or 0x...c8a0df..., the
converted values go wild.
Solution: Detect this error in configure.in and disable compiler
conversions from long double to (unsigned) long long for Mac OS 10.4
and IRIX64 6.5.
Platforms tested: h5committest, Mac OS 10.4, and IRIX64 6.5.
Bug fix.
Description:
Some machines (e.g., HPUX) will have off64_t defined but no support
for stat64 unless certain LargeFile macro is turned on. This caused
the last fix on H5private not quite right which caused compiling failures.
Solution:
Added stat64 and fstat64 tests and then will use them only if they
are supported.
Platforms tested:
Tested on kelgia, copper and heping (pll).
(Compiling alright but tests for kelgia and heping are not done.
expect no problems.)
bug fix.
Description:
Previous H5private.h would attempt to use the off64_t/stat64/etc
by checking just sizeof __INT64 being 8. This caused errors in
some machines like alpha cluster which is a 64bit machine. Its
compiler supports the type __int64 but it does not support
off64_t since its off_t is already 64bits big. The above code
casued the compiler to complain about the unknown off64_t and
such.
Solution:
H5private.h:
Changed the code to use the pseudo standard of off64_t/stat64/etc
only if sizeof(off_t) is not 64 bits AND sizeof(off64_t) exists
and is 64 bits. This assumes if off64_t is defined, all those
stat64, fstat64, etc are supported too.
configure.in:
configure:
Added the testing of sizeof(off64_t) to support the above solution.
Platforms tested:
h5committested. Also tested at LANL QSC.
new feature
Description:
1) separated the HL library into "public" and "private" header files, with the same caracteristics as the basic library
2) added the public headers to hdf5.h (with a conditional include macro, defined in configure.in)
3) added the path to HL in all Makefile.am 's , because of the inclusion in hdf5.h
Solution:
Platforms tested:
linux 32, 64
AIX
solaris
with fortran and c++
(one packet table example fails)
Misc. update:
"Hide" file format changes (for now)
Description:
Add ifdef's (controlled by the --enable-group-revision configure flag)
to disable group revision changes to the file format, in order to allow alpha
release to go ahead without releasing an unsupported version into the wild.
Platforms tested:
FreeBSD 4.11 (sleipnir)
Linux 2.4 32-bit (heping)
Linux 2.4 64-bit (mir)
Solaris 2.9 (shanti)
Bug fix/Feature
Description:
Modify the library to use rand_r, when available, instead of srand. If
rand_r is not available, it will try to use srandom/random, and then finally
fall back to srand/rand.
Solution:
A couple places in the library use the srand() function to seed the random
number generator. This can cause problems on certain platforms and could theoretically
cause problems for users who expect a certain sequence of random numbers following their
own call to srand().
Most platforms have an implementation of rand_r, which is identical to rand, except that
it allows for explicit storage of the seed value. The configure script will now check
for the existence of rand_r to facilitate its use in the library.
Two new functions are added, to replace the macros HDsrand/HDrand. These functions are HDrand and
HDsrand. HDrand will call rand_r, if available, or random(), if available, and fall back to rand() if neither
of those is available. HDsrand will store the seed value locally, if rand_r is available. Otherwise, it will call
srandom if available, and fall back to srand otherwise.
Platforms tested:
heping, mir. Really need to test on Red Storm, since that platform motivated this fix, but the machine
is currently not available.
Misc. update:
Bug fix
Description:
Fixed bug in hl/src Makefile that was deleting y.tab.c.
Running bin/reconfigure changed a few other files as well (somebody
probably updated Makefiles.am but forgot to bin/reconfigure).
Solution:
Automake in its wisdom adds the line "rm *.tab.c" to every distclean
in every directory. I assume that it assumes that such files are
generated during the build. Supplied an empty distclean-compile
target to remove this line from the Makefiles.in.
Platforms tested:
mir, sleipnir, shanti
Bug fix
Description:
Some platforms complain that tcp.h is present but cannot be compiled.
Solution:
This is because tcp.h needs in.h to be included.
Checked for netinet/in.h and included it when netinet/tcp.h is being
checked.
Platforms tested:
mir, cu11
Description: Added 2 new configure options, --enable-exception and --enable-accuracy.
--enable-exception lets the library check whether user's exception handling
functions are present during compiler data conversions and use them if they are.
When it's disabled, this step is skipped to improve conversion speed. This
step isn't implemented yet for soft conversions because there would be little
gain in speed.
--enable-accuracy guarantees data accuracy during data conversions. It means
the library will choose compiler conversions only if the accurate data is
secured. Otherwise, the library will go for the library's own conversions. If
this option is disabled, the library uses compiler conversions in favor of
their speed as long as they work even if data can be incorrect.
Platforms tested: h5committest and fuss. Some systems may fail after this
checkin.
