Code cleanup (sorta)
Description:
When the first versions of the HDF5 library were designed, I remembered
vividly the difficulties of porting code from a 32-bit platform to a 16-bit
platform and asked that people use intn & uintn instead of int & unsigned
int, respectively. However, in hindsight, this was overkill and
unnecessary since we weren't going to be porting the HDF5 library to
16-bit architectures.
Currently, the extra uintn & intn typedefs are causing problems for users
who'd like to include both the HDF5 and HDF4 header files in one source
module (like Kent's h4toh5 library).
Solution:
Changed the uintn & intn's to unsigned and int's respectively.
Platforms tested:
FreeBSD 4.4 (hawkwind)
More code cleanups
Description:
Wrap up the code cleanups for changing the dataset transfer property lists
over to using the generic property list code.
Platforms tested:
IRIX64 6.5 (modi4)
Code cleanups, mostly..
Description:
Work on pacifying the SGI compiler to get the generic properties working
correctly with --enable-parallel and --enable-fortran. It's not quite
fixed yet, but I need to head home and these patches help... :-/
Platforms tested:
IRIX64 6.5 (modi4)
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.
