Bug fix.
Description:
Left an extra '}' in when I removed the v1.2.x compat stuff.
Solution:
Took the '}' out... :-)
Platforms tested:
Solaris 2.7 (arabica)
Feature shift
Description:
Take out the v1.2.x compatibility stubs and put in the hooks for v1.4.x
compatibility when needed.
Platforms tested:
FreeBSD 4.3 (hawkwind)
Purpose:
Bug Fix
Description:
The way we were generating Dependencies and .depend files was broken.
If the $srcdir or other macros began with a ".", then it would match
anything and cause problems since it would then overwrite the
beginning of the header file's path.
Solution:
Wrote a Perl script which can handle this type of weirdness better.
It's only used when the environment is a GNU one with a GCC
compiler...
Platforms tested:
Linux
Purpose:
Bug fix (bug#625)
Description:
Character buffers were not copied and freed properly. That caused segmentation fault on Linux (Debian 2.2, a glibc2.1.3-based distro and gcc 2.95.2 and NAGWare Fortran 95 compiler Release 4.0a(392). Also many compilers screamed about this piece of code.
Solution:
Asked Quincey to fix the code.
Platforms tested:
Linux (eirene)
Purpose:
Bug Fix
Description:
the ptesthdf5_fortran.f90 program was dependent upon the THDF5
module. But before the ptesthdf5_fortran.lo file is build, the THDF5
module needs to be built.
Solution:
Put that dependency into the Makefile.
Purpose:
Bug Fix
Description:
*sigh* The change I made yesterday didn't work correctly. The shell
command interpretted the line as if it were command flags.
Solution:
Removed the "()"s from around the macro name so that they can be
expanded correctly.
Platforms tested:
Linux
Purpose:
Fix
Description:
Porting fixes from the 1.4 branch to the 1.5 branch. This fixes the
dependency problem in the testpar/ directory and also the problem
with module includes on the command line.
Purpose:
Bug Fix
Description:
In order for libtool to point to the place zlib lives (when
specified) it needs to add that flag to the LDFLAGS macro. However,
since we're getting this information from the top-level configure,
it's cached. Thus, we don't check for it and the -L flag doesn't get
included into the LDFLAGS macro.
Solution:
Remove the cached value so that the Fortran configure will always
check for zlib even if it's found by the top-level configure.
Platforms tested:
Kelgia
Bug Fix
Description:
Propagating changes from the 1.4 branch to the 1.5 branch. This
fix takes care of the problem of parallel make in the Fortran
directory.
Platforms tested:
Eirene and Modi4
Purpose:
Bug Fix
Description:
Modules weren't being found correctly.
Solution:
The F9XMODFLAG was being set and used in the test{par}/ and examples/
directories, but it's also needed in the src/ directory.
Platforms tested:
Modi4...cross fingers...
Purpose:
Bug Fix
Description:
Changed the order of the flags checking for modules from -M -I to -I
-M. Elena already fixed it in the configure ifle. This puts it in the
acsite.m4 file so that it will be propagated to future configure
builds.
Purpose:
Maintenance on IBM SP
Description:
I used unnecessary system specific compiler falgs
Solution:
Removed unnecessary flags
Platforms tested:
NERSC IBM SP (gseaborg)
Purpose:
Bug bypass
Description:
Fortran configure checks flags where to find F90 modules in the
order "M", "I" and "p". On IBM SP "M" is a reserved flag, configure
does not understand compiler's warning and uses it to specify
module directories. Then tests and examples compilation fails since
module directory is not specified correctly on the compilation line.
Solution:
Changed the order of flags to be "I", "M", "p", so configure on IBM SP
finds the correct flag first.
Platforms tested:
NERSC IBM SP (gseaborg)
Purpose:
IBM SP F90 HDF5 Library port
Description:
Added necessary type definitions for the port
Platforms tested:
Tested only for 1.4. branch. 1.5 branch will be tested later.
Purpose:
DEC UNIX port
Description:
Windows port caused problems on DEC UNIX.
Names of C functions called from F90 subroutines were converted
to UPPER case while DEC UNIX expected them to be in lower case.
Solution:
Added special DEC compiler directives to avoid the conflict on two
systems
Platforms tested:
Windows98, DEC UNIX, Linux
Purpose:
HPUX 11.00 port
Description:
Redundant USE statements triggered a bug in the HP F90 compiler.
Solution:
Source code was rearranged to avoid redundancy: definitions of the
object and dataset region reference types were moved from H5Rff.f90
to H5f90global.f90; "USE H5R" statement was removed from H5Rff.f90.
Now H5Rff.f90 uses "USE H5GLOBAL" statement only as the rest of
the modules.
Platforms tested:
HPUX 11.00 (kelgia), Solaris 2.7 (arabica)
Purpose:
Bug fix
Description:
There was a syntax error on Windows, and I fixed it long time ago but forgot
to check this file into CVS.
Solution:
Fix the error.
Platforms tested:
Windows98
Purpose:
Windows port
Description:
Names of the H5f.c and H5ff.f90 files caused problems on Windows98.
Compilation of H5F.c (C Library) and H5Ff.f90 (Fortran library)
as compilation of H5f.c and H5ff.f90 creates the same H5F.o and H5FF.o
file names and linking stage fails.
Solution:
Rename the files to H5_f.c and H5_ff.f90
Platforms tested:
Linux (eirene) and Windows98
Bug Fix
Description:
The "-$(RM)" flags were causing error messages when doing a make
distclean.
Solution:
Removed the "-" from the beginning.
Platforms tested:
Linux
Purpose:
Codemaintenance
Description:
read/write APIs have been changed.
Solution:
Made necessary changes to the source code.
Platforms tested:
Linux, Solaris 2.7, O2K, T3E
Purpose:
Code maintenance
Description:
read/write APIs have been changed.
Solution:
Made necessary changes to the tests.
Platforms tested:
Windows 98, Linux, Solaris 2.7, O2K, T3E
Purpose:
Windows port
Description:
Multiple changes:
* Windows platforms require special compiler directives
in order to create DLLs.
* In read/write subroutines data arrays were passed by descriptor.
This worked on UNIX but did not work on Windows.
Solution:
* added compiler directives.
* read/write APIs have been changed. There is an additional
parameter (array that contains the sizes of data buffer dimensions)
and regular arrays are used instead of assumed-shaped arrays.
Platforms tested:
* Currently this feature does not work. Common blocks are not exported correctly
from one F90 module to another.
I am checking this in so I can ask DEC for help.
* For static library tests passed on Windows 98 ( except flush2_fortran)
All tests passed on Linux, Solaris 2.7, O2K and T3E
Cleanup
Description:
If there isn't anything to "remove" during the cleanup faze. This
stops the "make clean"s from printing out:
rm -f
all of the time.
Solution:
Check if hte macros have anything in them before calling the rm.
Platforms tested:
Linux
Portability changes
Description:
Very quick port to Compaq (nee DEC) Alpha OSF5.
Solution:
Added a new "dec-osf5.x" configuration file and changed configure.in
to look for it.
The local test machine is now passing all the tests, except I can't get
the "-L<path>" stuff to work, so tools which depend on the HDF4 library
around tested.
Platforms tested:
Compaq Alpha 5.1 (compaq.ncsa.uiuc.edu)
Bug Fix
Description:
If we need to specify a -R flag for dynamic libraries (like, in the
case when we specify --with-hdf4), then this flag needs to be added
to the linking line so that it will show up in the generated library
and other programs linking to that library will be able to find the
relevant libraries.
Solution:
Added the DYNAMIC_DIRS macro to the link line.
Platforms tested:
Arabica
Bug Fix
Description:
Create a Makefile in the testpar/ directory only if PARALLEL is
enabled.
Solution:
Set a macro to the testpar/Makefile for the generation script.
Purpose:
Maintenance
Description:
[describe the bug, or describe the new feature, etc]
Solution:
Added comment block to each subroutine.
Platforms tested:
NONE, do it later.
Purpose:
Windows port and maintenance
Description:
Each C function called from F90 subroutine requires explicit
interface. Some drivers functions were not implemented.
Solution:
Added interfaces and comment blocks to each F90 subroutine.
Added the following subroutines:
h5pset(get)_fapl_core_f
h5pset(get)_fapl_family_f
h5pset_fapl_sec2_f
h5pset_fapl_stdio_f
Platforms tested:
Linux (eirene) to make sure that code still works on UNIX.
More UNIX platforms will be tested before moving to Windows.
Purpose:
Window port and maintenance
Description:
Windows Fortran requires interface blocks for each C function
called from F90 stub.
I also added comment blocks for each F90 API and fixed minor bugs
in enum datatype routines that are not official yet.
Solution:
Added interface blocks.
Platforms tested:
Linux (eirene)
Purpose:
Window port and maintenance
Description:
Windows Fortran requires interface blocks for each C function
called from F90 stub.
I also added comment blocks for each F90 API.
Solution:
Added interface blocks.
Platforms tested:
LINUX (eirene)
Purpose:
Windows port and maintenance
Description:
Windows Fortran requires interface blocks for each C function
called from F90 stub.
I also added comment blocks for each F90 API.
Solution:
Added interface blocks.
Platforms tested:
Linux (eirene)
Purpose:
Bug fix
Description:
Function name h5rget_object_type_obj_f was used in test program
instead of the generic name h5rget_object_type_f.
Solution:
Changed the name.
Platforms tested:
Linux (eirene)
Purpose:
Windows port and maintenance
Description:
Windows Fortran requires interface blocks for each C function
called from F90 stub.
I also added comment blocks for each F90 API and fixed several typos.
Solution:
Added interface blocks.
Platforms tested:
Linux (eirene) to test that things are not broken on UNIX.
Purpose:
Windows port and maintenance
Description:
Windows Fortran requires interface bocks for each C function called from F90 stub. I also added comment blocks for each F90 API.
Solution:
Added interface blocks.
Platforms tested:
Linux (eirene) to test that things are still working on UNIX.
Purpose:
Windows port and maintenance
Description:
Windows Fortran requires interface bocks for each C function
called from F90 stub.
I also added comment blocks for each F90 API.
Solution:
Added interface blocks.
Platforms tested:
Linux (eirene) to test that things are still working on UNIX.
Purpose:
Windows port and maintenance.
Description:
Windows Fortran requires explicit interface block for each
C function called from F90 stub.
I also added comment block for each F90 function.
Solution:
Added inteface block for each function.
Platforms tested:
Linux (eiriene): checked that code is still compiles and runs correctly
on UNIX.
Bug fix
Description:
The /bin/csh shell was causing problems if you were using a different
shell than csh (like bash). It couldn't find the compiler.
Solution:
Changed to the more standard /bin/sh
Platforms tested:
Linux
New platform
Description:
Support the Cray SV1 machine. (config file is identical to unicosmk file
right now).
Platforms tested:
Cray SV1 (killeen.nersc.gov)
Purpose:
Bug fix
Description:
Compilation failed for the H5f90global.f90 file on DEC UNIX (hdf5-1.4.0-beta3-pre2)
When new definition H5E_TBBT_F was added, the length of the corresponding
H5E_flags array was not increased.
Solution:
Fixed the length of the array.
Platforms tested:
DEC UNIX (gondolin)
Purpose:
Bug fix.
Description:
While building on T3E, I noticed several compiler warnings about
variable being used before its value was defined.
Solution:
Fixed.
Platforms tested:
T3E (mcurie.nersc.gov)
Bug Fix
Description:
Small bug fix to the acsite.m4 stuff. We should check if the Fortran
9X compiler was found instead of the CC compiler.
Solution:
Changed CC to F9X macro.
Platforms tested:
Linux
Bug Fix
Description:
The test ``test -e "filename"'' doesn't work with some Bourne shells
(for instance, on Arabica).
Solution:
Changed test to ``test -f "filename"''.
Platforms tested:
Arabica
Bug fix
Description:
This should fix the problem with installing the Fortran module
files.
Solution:
This script determines if the HDF5 module is created. If it is,
then we assume that we need to install all of the modules. I
check for both upper and lowercase in the name cause I'm not sure
what weird fortran compilers will do.
Platforms tested:
Linux
Another fix...
Description:
This should work for all platforms now. The other fix didn't work
for the Linux platform
Solution:
Explicitly copy the modules if they exist.
Platforms tested:
Linux
Bug Fix
Description:
When trying to install the Fortran Modules, it would barf if
there weren't any files in the directory with that extension
(i.e., in the test/ directory).
Solution:
Changed the installation to install only those files which
actually have the correct extension we want.
Platforms tested:
This type of fix works on the T3E and Linux
Install Fix
Description:
Fortran modules need to be installed.
Solution:
I check for the extension modules are created with and use that
during the install...
Platforms tested:
Linux
Purpose:
Maintenance
Description:
Not all platforms support F90 MPI. I used USE MPI statement, and
it did not work on T3E (mcurie.nersc.gov)
Solution:
Use INCLUDE 'MPIF.H' statement instead of USE MPI.
Platforms tested:
O2K and T3E
Bug Fix
Description:
Parallel stuff wasn't being compiled on T3E. It was complaining
about not being able to find said files. Also, I was confused
about which Fortran module needed to be compiled when it was
parallel.
Solution:
Did magic so that the correct files are specified when parallel
is enabled.
Platforms tested:
T3E
New Config
Description:
T3E at mcurie.nersc.gov changed it's name yet again.
Solution:
Create new file so that configure will find it correctly.
Platforms tested:
T3E
Bug Fix
Description:
The fix we put in to ignore warning 405 was incorrect. The quotes
were confusing to configure.
Solution:
Turns out that there doesn't need to be a space between the -M
flag and the warning number.
Platforms tested:
T3E
Purpose:
Bug fix on T3E.
Description:
There was a typo in the h5init_types_c name translation line that
caused compilation errors.
Solution:
Fixed the typo. This fix exposes another error and I have no clue what to
do about this one
f90 -p. -p../src -dp -o fortranlib_test fortranlib_test.o hdf5test.o tH5F.o tH5D.o tH5R.o tH5S.o tH5T.o tH5Sselect.o tH5P.o tH5A.o tH5I.o tH5G.o ../src/.libs/libhdf5_fortran.a ../../src/.libs/libhdf5.a -L/u3/epourmal/HDF4/NewHDF/lib -lmfhdf -ldf -ljpeg -lz -lnsl -lm
cld-405 cld: WARNING
The entry point `HDF5' defined in relocatable object `../src/.libs/libhdf5_fortran.a[HDF5.o:HDF5]' is used; the definition in relocatable object `./../src/HDF5.o:HDF5' is ignored.
cld-431 cld: WARNING
The resulting output file `fortranlib_test' is not executable because of previous WARNING messages.
Make: "../../libtool --mode=link f90 -p. -p../src -dp -o fortranlib_test fortranlib_test.lo hdf5test.lo tH5F.lo tH5D.lo tH5R.lo tH5S.lo tH5T.lo tH5Sselect.lo tH5P.lo tH5A.lo tH5I.lo tH5G.lo ../src/libhdf5_fortran.la ../../src/libhdf5.la": Error code 1
cmd-2436 make: Stop.
+ exit 1
Make: "set -x; for d in src test examples; do \
(cd $d && make tests) || exit 1; \
done": Error code 1
Platforms tested:
T3E
Bug Fix
Description:
We were not propagating the FFLAGS macro. I.e., we were
overwriting it after it was set in the commence.in includes.
Solution:
Include it with a ``@FFLAGS@'' where we'd normally overwrite it
so that it isn't.
Platforms tested:
T3E
Attempted Bug Fix
Description:
Some machines (Cray T3E, need you ask?) use the ``-p'' flag for
enabling double precision. This breaks our Fortran interface.
Solution:
Put this test last. However, the T3E apparently doesn't need
modules, so we may have to resort to a better "fix" than this
in the future.
Platforms tested:
T3E
Purpose:
Bug fix
Description:
hdf5 1.4.0_beta1 build failed for Fortran test tH5T.f90 because
third argument of the h5tarray_create_f subroutine had INTEGER(SIZE_T)
type instead of INTEGER(HSIZE_T) type.
Solution:
Fixed the datatype.
Platforms tested:
Linux (eirene)
Purpose:
Bug fix.
Description:
H5f90global.f90:
One of the common block arrays (floating_types) had a typo in the name.
DEC compiler was the only compiler to warn about the problem.
H5Ff.f90
Compiler gave warnings about a variable that was used before its value was defined.
Fixed. Turned to be a typo in a variable name.
Platforms tested:
DEC UNIX (gondolin)
Purpose:
Bug fix
Description:
Test program was using h5init_types_f and h5close_type_f
instead of h5open_f and h5close_f. Would not compile on modi4.
Solution:
Fixed the code to use new functions.
Platforms tested:
O2K (modi4)
Purpose:
Bug fix
Description:
h5gget_linkval_f function had an argument with the type INTEGER instead
on INTEGER(SIZE_T). Test would not compile on O2K.
Solution:
Fixed argument datatype.
Platforms tested:
O2K (modi4)
Purpose:
Bug fix
Description:
Functions were using flags that were not defined anymore.
Somehow I forgot to check this file in when I modified code
to use run-time generated flags.
Platforms tested:
O2K (modi4)
Bug Fix
Description:
T3E and J90 were complaining about not being able to make for
ADD_PARALLEL_FILES.
Solution:
Somehow the make on these machines must have been weirded out by
the funky pattern matching/replacement that's being done and
couldn't handle a null macro. I now assign "no" to the macro
explicitly
Platforms tested:
T3E
Purpose:
Code maintenance and development
Description:
I added two functions h5open_f and h5close_f to initialize
C library and Fortran interface (flags, predefined datatypes, etc).
Those calls are required for any F90 program that uses HDF5.
I renamed H5f90misc.c and H5f90miscf.f90 files to H5f.c and H5ff.f90.
New functions are added to those new files.
Platforms tested:
Solaris 2.6
Purpose:
Bug fix
Description:
HP and AIX compilers did not like duplicate array declarations in
common blocks statements.
Solution:
Removed duplication
Platforms tested:
SP2 and HPUX 11.00
Purpose:
Code maintenance
Description:
Fixed the code to use new h5tarray_create_f subroutine to
create a compound datatype with an array field.
Platforms tested:
Solaris 2.6
Purpose:
Bugs fix
Description:
I used H5Tcreate_array instead of H5Tarray_create in C stub
Solution:
Fixed
Platforms tested:
Solaris 2.6
OCVS: ----------------------------------------------------------------------
Purpose:
Code development and maintenance
Description:
Four new fortran functions to support array datatype were added:
h5tarray_create_f
h5tget_array_ndims_f
h5tget_array_dims_f
h5tget_super_f
Two functions were deleted (commented out for now, can be returned easily if
necessary):
h5tinsert_array_f
h5tget_member_dims
Platforms tested:
Library build was tested on Solaris2.6. I have to modify test program to
use new functions. Right now test program will not compile.
Buglet fix
Description:
Was removing the confdefs.h header which was needed during
Makefile generation.
Solution:
Stopped doing that.
Platforms tested:
Linux
Buglet fix...
Description:
When configuring, configure would complain about there not being
a confdefs.h file.
Solution:
Added a src/H5config.h file which configure can generate. This
can be used for configure stuff later, but is empty now.
Platforms tested:
Linux
Purpose:
New feature
Description:
Added F90 flags to support h5glink_f subroutine
H5G_LINK_ERROR_F
H5G_LINK_HARD_F
H5G_LINK_SOFT_F
Platforms tested:
Linux (eirene)
Purpose:
New feature
Description:
Now all Fortran flags such as H5F_ACC_RDONLY_F (previously defined in the
H5fortran_flags.f90 file) are generated at runtime when h5init_fortran_f
subroutine is called. All flags have now the same value as
corresponding C flags. This change affects user's programming model:
Every Fortran program that uses F90 HDF5 Library has to call
h5init_fortran_f(error) subroutine before the first call to the
F90 HDF5 Library and h5close_fortran_f(error) after the last call to the
Library. h5init(close)_types_f calls are not needed anymore since
F90 datatypes are intialized(closed) with the h5init(close)_fortran_f
calls.
Platforms tested:
O2K and Solaris2.7
Purpose:
Bug fix.
Description:
When the number of processors is wrong (should be a factor
of dataset dimensions for this test) , test hangs because
of wrong logic in the if-then-endif statement.
Solution:
Fixed the logic.
Platforms tested:
modi4 (O2K)
Purpose:
Bug fix.
Description:
Reading from the file failed because property list identifier
was not properly passed to the subroutine h5dread_f.
Solution:
Fixed the order of the parameters in the h5dread_d call
Platforms tested:
O2K (modi4)
Purpose:
Adding F90 || tests.
Description:
I created testpar directory with the following files
ptesthdf5_fortran.f90 - F90 test driver program
tcheck.f90 thdf5.f90 - handy subroutines to use with the tests
thyperslab_wr.f90 - F90 test:
collectively writes and reads hyperslabs to/from the dataset
Solution:
Platforms tested:
Partially tested on modi4 (O2K)
Bug fix...I hope
Description:
For some reason, libtool wasn't generating a .lai library file in
the .libs directory. It needs this to install things, apparently.
Solution:
Major hack! I force a ln to the "real" one libtools wants.
Platforms tested:
Modi4
Purpose:
Maintenancece.
Description:
F90 APIs would not compile anymore for || version..
Solution:
Replaced old functions h5pset(get)_mpio, h5set(get)_xfer with
ones h5pset(get)_fapl_m and h5pset(get)_dxpl_mpio_f
Platforms tested:
O2K.
Purpose:
Bug fix.
Description:
fortranlib_test.f90 had a typo in the format string. Would not compile on O2K.
Test did not check the length of the attribute name.
Solution:
Fixed format strings.
Added more code to test returned attribute name length.
Platforms tested:
O2K, Linux
Purpose:
Bug fix
Description:
Attribute test failed on O2K. h5aget_name_f function could not
return correct attribute name.
Solution:
size function parameter had wrong datatype in F90 subroutine.
Fixed it to be of INTEGER(SIZE_T) type.
Platforms tested:
O2K, Linux
Bug Fix
Description:
Getting messages while compiling the || fortran stuff that it
didn't have a rule to make "H5Pf_parallel.c".
Solution:
The quotes were confusing it. I placed the text in another macro
to fix this.
Platforms tested:
Modi4
Purpose:
Added more Fortran tests
Description:
tH5A.f90 - attribute interface test
tH5I.f90 - identifier interface test
Solution:
Two new files were added to test H5A and H5I interfaces.
Platforms tested:
Solaris 2.7, Linux
Purpose:
H5Aff.f90: Bug fix
Description:
Character string was not passed correctly from the user's application
to the write/read subroutines when buffer was decalred as assumed-shape
array.
Solution:
Declared date buffer to be assumed-size array.
Platforms tested:
Solaris 2.7, Linux
Purpose:
H5fortran_flags.f90: Bug fix
Description:
Fortran H5I_* types had incorrect values.
Solution:
Fixed.
Platforms tested:
Solaris 2.7, Linux
Bug Fix
Description:
Sed was complaining about "filename expected" when trying to
generate the .in files. The problem stemmed from the script sed
was generating in the conftest.s1 file. It needed the DEPEND
filename which wasn't being set.
Solution:
Fixed so that we check if DEPEND is zero before trying to set if
(if not using a GNU make program) instead of testing if DEPEND
has a value in it...I copied this incorrectly from the main
library's configure.in file...my bad.
Platforms tested:
T3E
Bug Fix
Description:
On some platforms, if you don't have . in your PATH, it won't
find the test program it's supposed to run.
Solution:
Changed instead to ./$$test so that it picks up the program in
the current directory.
Platforms tested:
Opus and Linux
Feature Missing
Description:
Generate the Dependencies files so modules are regenerated
correctly
Solution:
Handcoded the module. Hope it works.
Platforms tested:
Bug Fix
Description:
When doing a make clean, the H5fortran_types.f90 file would be
removed.
Solution:
Placed it in the DISTCLEAN macro instead of the CLEAN so that it
will stick around.
Platforms tested:
Purpose:
Fortran HPUX 11.00 port
Description:
Added Fortran stuff to the hpux11.00 file
Platforms tested:
Has not been tested yet. Will do it after this checkin on opus.
Bug fix
Description:
The setting does not work for the --srcdir option as source file names
are hard set in the action lines.
Solution:
Changed the dependence targets to the form of *.lo and the action lines
would use the *.lo files. This way, *.lo files are created when
-srcdir option is used or not. Also added that they all depend on
the C hdf5 library.
Platforms tested:
IRIX64 -64 with --srcdir
Bug fix
Description:
The setting does not work for the --src-dir option as source file names
are hard set in the action lines.
Solution:
Changed the dependence targets to the form of *.lo and the action lines
would use the *.lo files. This way, *.lo files are created when
-src-dir option is used or not.
Platforms tested:
IRIX64 -64 (I knows it works for other platforms because
"'I know the hammer will drop when i let go'--Mr. Spock")
Bug Fix
Description:
I was relying on the PARALLEL macro to be "yes" or "no" all the
time. This isn't the case.
Solution:
Created the ADD_PARALLEL_FILES macro to do just this.
Platforms tested:
Modi4
Bug Fix
Description:
Wasn't picking up the header files from the proper source and
build directories. There were some funky things happening in
there.
Solution:
Put the correct path in.
Platforms tested:
Modi4
*sigh*
Description:
Wasn't picking up a header file which is in the source directory.
Solution:
Changed some flags so that it does this now.
Platforms tested:
Modi4
Bug Fix 37
Description:
Okay...this is really it now. Sorry for all the other "fixes".
This will take care of the top_builddir macro for the Fortran
interface.
Solution:
Hardcoded the path to the build directory.
Platforms tested:
Modi4.
Bug Fix
Description:
Wasn't finding the Dependencies file when doing a make.
Solution:
Modified the path to the Dependencies file by prepending a
`$(srcdir)/' to it.
Platforms tested:
Modi4
Bug Fix
Description:
The "fix" for search paths was wrong. It would try to recompute
the SEARCH macro at the end.
Solution:
Stopped it from doing that if the $SEARCH macro has a value. One
question, will fortran always be built from the top directory?
Platforms tested:
Modi4
Bug Fix
Description:
When running configure on subdirectories (like fortran/), looking
up how make implements SEARCHes failed.
Solution:
Exporting the SEARCH macro so that subdirectories don't have to
look for it.
Platforms tested:
Modi4.
Purpose:
Buf fix
Description:
On DEC, H5Dff.f90 would not compile because of variables declaration
order. Other UNIX platforms including J90 did not care.
Solution:
Change the order of variables declarations.
Platforms tested:
DEC Unix (gondolin)
Purpose:
Updated source code to use new APIs to write/read references
Description and Solution:
Write/read subrotine has extra parameter - size of the reference array.
I modified the source to reflect this change.
Platforms tested:
Solaris 2.6
Purpose:
Reimplemented references to the objects and dataset regions.
Description:
Previous implementation was not portable. This implementation
should work on UNIX workstations and Crays, but is very inefficient
since it uses memcpy to repack Fortran buffers with references
to C buffers and vice versa.
Solution:
I used fortran derived datatype with integer fields. h5dwrite_f and
h5dread_f have extra parameter when references are written or read.
This parameter describes size of the buffer that holds references.
Platforms tested:
J90 and Solaris 2.6
H5Pf.c
Some of the functions do not exist now in the development branch.
Commented those out, so one does not need to apply patch in order
to build Fortran Library.
Adding the Fortran interface to the HDF5 library
Description:
Fortran is now a subdirectory of the HDF5 library tree.
Platforms tested:
Solaris and IRIX (O2K)