If the AR command has embedded shell separators such as the case of
"AR = ar -X 64", $AR ends up as a blank.
Solution:
Put quotes around the command substitution string to protect against embedded
separators. Applied the same to both AR and RANLIB assignments.
Tested:
At Up (AIX 5.3) only because that was where I discovered the error
when AR is ar -X 64
H5D_CHUNK_CACHE_NSLOTS_DEFAULT_F
H5D_CHUNK_CACHE_NBYTES_DEFAULT_F
H5D_CHUNK_CACHE_W0_DEFAULT_F
to
H5D_CHUNK_CACHE_NSLOTS_DFLT_F
H5D_CHUNK_CACHE_NBYTES_DFLT_F
H5D_CHUNK_CACHE_W0_DFLT_F
to get under the 31 limit for variable names
H5D_CHUNK_CACHE_NSLOTS_DEFAULT_F
H5D_CHUNK_CACHE_NBYTES_DEFAULT_F
H5D_CHUNK_CACHE_W0_DEFAULT_F
to
H5D_CHUNK_CACHE_NSLOTS_DFLT_F
H5D_CHUNK_CACHE_NBYTES_DFLT_F
H5D_CHUNK_CACHE_W0_DFLT_F
to get under the 31 limit for variable names
- Updated bin/reconfigure to use latest version of automake (1.10.2).
Re-generated 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
Fixed warnings from absoft's compiler for !DEC$ statements.
Solution: There should not be a space after !DEC$ statements, removed the spaces.
Platforms tested:
Jam with gcc and f95
Bug Fix
Description:
Fixing BZ #1381. The --includedir=DIR configure option, which is used
to specify the installation location of C header files, did not work
correctly as the path was hard-coded in 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 to allow customization of this value.
Tested:
jam, liberty
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: h5committest
*Fixed cd_nelements in nh5pget_filter_c - cd_nelments not pased in or returned correctly. Since
cd_nelmts has IN/OUT attributes, fixed the input and
returned value of cd_nelmnts to satisfy this specification.
*Fixed 'name' returned in nH5Pget_external_c - if the size of the fortran buffer is larger then
the returned string from the function then we need to give HD5packFstring the
fortran buffer size so that it fills the remaining unused characters with blanks. Found
with the gfortran compiler.
Platforms tested: smirom, liberty
Description:
- Remove need to set LD_LIBRARY_PATH when using shared szip library.
- Libtool 2.2.6a is now used to generate libraries.
- 'make check install' dependency bug is fixed, and should no longer
break the build.
- removed hard coding of shell in config/commence.am, as this causes
problems on Solaris with the new version of libtool.
- RELEASE.txt with appropriate changes.
Tested:
- kagiso, smirom, linew (merged from 1.8, pretty quick tests)
Description:
Visual Studio compiler was complaining because variables were declared mid-function, when they should be declared at the top. This checkin simply moves the declarations to the top.
Tested:
Simple edit, VS2005 only
We check for all the available reals in Fortran and if 16 byte real is available in Fortran and not in C then we disable the 16 byte real in Fortran. Also added the test for 12 byte real in Fortran so that it can match the 12 byte float in C if available. Note: if KIND=10 and KIND=16 are both avaiable as when using g95, then it may be the case on some systems that the size of KIND=10 and KIND=16 are both 16 bytes, so the program will print twice in H5fort_type_defines.h
#define H5_FORTRAN_HAS_REAL_16
which should not cause any errors.
Removed refences to "double" so that we don't distinguish between writeDoubleToFiles and writeFloatToFiles such that we match the definitions of c_float_4, c_float_8, and c_float_16 in H5f90i_gen.h
Changed the datatype test programs such that we don't distinguish between writeDoubleToFiles and writeFloatToFiles so that we only define c_float_4, c_float_8, and c_float_16 in H5f90i_gen.h
Added the definition of real_4_f, real_8_f, real_16_f depending on if they are available, also in H5f90i_gen.h
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
Description:
We recently moved the Windows-specific fortran source code into a separate file for specifying DLL exports. However there were a couple definitions missing in the port from 1.8 to the trunk branch. This checkin correctly includes the .def file into our Windows project, and adds the missing definitions to hdf5_fortrandll.def.
Tested:
VS2005 on WinXP
