Code Cleanup
Description:
Warning messages were being produced by the "make" program because
the "docdir" was being specified twice as a target in the generated
Makefiles. This is because the "EXAMPLESDIR" was also defined as
"docdir".
Solution:
Made "EXAMPLESDIR" unique for C, Fortran, and C++ in the commence.in
file and removed EXAMPLESDIR from the Makefile.ins
Platforms tested:
Dangermouse (only affects make system, not code).
Misc. update:
Purpose: Maintenance
Description: I changed release version to 1.5.54.
Email about tetsing of 1.5.53 will be send after this checkins.
Solution: used bin/h5vers -s to change the version number
Platforms tested: Done on arabica
Misc. update:
Purpose: Fortran updtae
Description: Created new functions h5pset(get)_fapl_mpiposix_f
Platforms tested: Compilation was tested with semi-manual h5committest.
(I ahd to built and test manullay on modi4 parallel because
of some weird failure of h5committest on modi4)
There are no tests yet for those functions. Kent was
going to use them in the MEAD project to test
the performance.
Misc. update:
Purpose: Maintenance for T3E
Description: Cray updated T3E to run unicosmk2.0.6.X
Configuration failed.
Solution: Created new unicosmk2.0.6.X files in the config and fortran/config
directories and added them to MANIFEST. I had to disable warning
# 412 for fortran compilation. The warning would prevent creation
of executable programs.
Platforms tested: Cray T3E
Misc. update:
Fix
Description:
Fortran's configure was trying to read the "README.txt" file from the
"$srcdir", where it won't be.
Solution:
Changed it to look in "$srcdir/.." for the "README.txt" file.
Platforms tested:
Verbena. Configure only, so no need for full tests.
Misc. update:
Purpose: Maintenance/code cleanup/fight with Windows Fortran DLLs
Description: While strugling with Fortran DLLs on Windows I noticed
some missing export definitions that are necessary
for exporting correctly data and functions.
Solution: Added missing definitions
Platforms tested: h5committested; Windows with MSVC++ and Visual Fortran
on Windows. Fortran DLLs partially work, only 2 tests
fail, but failure doesn't make any sense. To make
things worse, most of the C DLL tests start to fail when
Fortran is built. I am still investigating...
Misc. update:
Purpose: Windows maintenance and code cleanup
Description: There were a lot of places in the source code where varibale
was declared but never used.
Solution: Cleaned the source code to avoid warnings on Windows adn Unix
platforms.
Platforms tested: arabica, modi4, Windows
Probably my environment is wrong on Linux, cannot
compile at all when fortran is enabled
If daily tests fails tomorrow, this will be my fault
but I want to go home now :-)
Misc. update:
Improvment
Description:
No default setting of fortran compiler when --enable-parallel is
used.
Solution:
Changed it to use mpxlf_r as the default parallel fortran compiler.
This is consistent with the default C compilers.
Platforms tested:
Did not h5committested because the changes were made offsite.
Tested in LLNL SP BLUE, both serial and parallel modes.
(There is a compiling error in src but the configure result are
verified.)
Misc. update:
Update MANIFEST if you add or remove any file.
Update release_docs/RELEASE for bug fixes, new features, etc.
Update applicable document files too.
bug fix
Description:
The default of CC used to be gcc which is not compatible with the
default fortran compiler of xlf.
Solution:
Copied the CC default setting from the C-API level.
Platforms tested:
Run test in Copper since this is a purely AIX change.
Misc. update:
Bug Fix
Description:
In parallel mode, the MPI libraries were being added to the LDFLAGS
variable instead of the LIBS variable. This was playing havoc with
the h5fc script (the order you specify libraries is important to some
compilers).
Solution:
The AC_CHECK_FLIB macro was placing these libraries into the LDFLAGS
instead of LIBS, which is where they should have gone. Replaced
LDFLAGS with LIBS in that case.
Platforms tested:
Modi4 (Parallel & Fortran)
Arabica (Fortran)
Verbena (Fortran, no C++ since it's not affected)
Ran "make check-install" after installation...
Misc. update:
Bug Fix
Description:
On Kelgia, building of the Fortran stuff would fail because of a bad
commandline. A "" was being put into it.
Solution:
I was stupid and put quotes around a variable in the commence.in file
when I shouldn't have. Removed those quotes.
Platforms tested:
Kelgia (Fortran)
Verbena (Fortran, no C++ since Fortran only)
Arabica (Fortran)
Modi4 (Fortran & Parallel)
Misc. update:
Bug Fix
Description:
When going to compile on a platform (like HP-UX) which doesn't have
libz.a in it's path, the script would fail. The reason was that the
LDFLAGS variable which holds the directories to these libraries was
last in the compile line. So the compiler couldn't find the library
Solution:
Put the LDFLAGS variable before the linker variables.
Platforms tested:
Kelgia (Fortran)
Verbena (Fortran, no C++ since only Fortran affected)
Arabica (Fortran)
Modi4 (Fortran & Parallel)
Also ran "make check-install"
Misc. update:
Bug Fix
Description:
H5FC was failing on Copper (IBM P690). The reason: the xlf compiler
needs files to end in .f in stead of .f90. If you have .f90 files,
you need the "-qsuffix=f=f90" flag defined. This was defined for
compiling things via the "-c" option (to object files) but not for
straight compilation of a file.
I also noticed that the directory modules were being extracted from
was "." and "../src". H5FC would find these alright when doing a
"make check-install" but if Suzie User were to try this, it might
fail for her. Suzie would have to specify explicitly where to grab
these files.
Solution:
The solution to the problem was a bit more involved. I added a new
variable called "F9XSUFFIXFLAG" which is set to this value if the
machine needs it.
Added new variable called "FSEARCH_DIRS" which can be set to the
directories to find modules during compilation. The H5FC script knows
where to find the correct modules (it's in the lib/ directory), so it
uses the F9XMODFLAG to find them and not the FSEARCH_DIRS flag.
Platforms tested:
Modi4 (Fortran & Parallel)
Verbena (Fortran) C++ not needed since this is Fortran-only fix
Arabica (Fortran)
Copper (Fortran)
Ran "make install" and "make check-install" afterwards...
Misc. update:
Update
Description:
Ran "autoheader" to gather some of the added #defines that were
included in the configure.in file over the months...
Platforms tested:
Arabica & Baldric (Fortran)
Modi4 (Parallel & Fortran)
Verbena (C++ & Fortran)
All with --enable-stream-vfd and doing a "make check-install".
Misc. update:
Bug Fix
Description:
The h5fc script couldn't find the correct libraries needed when it
was used on Solaris and the --enable-stream-vfd was enabled.
Solution:
Added checks for the -lnsl and -lsocket libraries if we're on Solaris
or HP-UX.
Platforms tested:
Arabica & Baldric (Fortran)
Modi4 (Parallel & Fortran)
Verbena (C++ & Fortran)
All with --enable-stream-vfd and doing a "make check-install".
Misc. update:
Bug fix and feature
Description:
The patch to Makefile.in failed if an empty directory of fortran/examples
was left behind by a previous build.
Solution:
Attempted to put it in config/conclude.in just became a mess since
it is hard to predict when we will include examples in the subdirs
or not.
Borrow the structure of install-examples and do some handcode per
interface. The Makefile.in of each interface (C, Fortran, C++)
controls everything. Not very systematic but pretty clean for this
case.
Platforms tested:
h5committested.
Also tested in modi4 with various combinations of fortran, c++
enabled.
Misc. update:
Purpose: Added copyright statement; cleaned code and fixed bugs for
Windows and Cray T90IEEE
Description: Windows and Cray ports exposed few typos in the source code
that caused tests to fail
Solution: Added copyright statement and clean the code.
Platforms tested: CRAY T90IEEE, arabica, modi4 with parallel, Windows 2000
Only static tests (both debug and release) passed on Windows.
DLLs have multiple problems ;-)
Misc. update:
Purpose: Added copyright statement; cleaned code and fixed bugs for
Windows and Cray T90IEEE
Description: Fortran files did not have copyright statement; VL types
did not work on T90IEEE since I never brought the correct code
from 1.4 branch; there were compilation warnings on Windows;
some character parameters were not passed correctly to C stubs
causing tests to fail on Windows.
Solution: Added copyright statement and clean the code.
Platforms tested: CRAY T90IEEE, arabica, modi4 with parallel, Windows 2000
Only static tests (both debug and release) passed on Windows.
DLLs have multiple problems ;-)
Misc. update:
Purpose: Catching up with 1.4 branch
Description: 1.5 didn't have unicos10.0.X configuration files
for both C and fortran.
Solution: Added the files
Platforms tested: CRAY T90IEEE
Misc. update:
Purpose: Catching up with C library
Description: I added tests for new functions
h5pset_szip_f
h5pget_filter_by_id_f
h5pall_filters_avail_f
I am not sure how to test h5pmodify_filter_f.
Solution:
Platforms tested: arabica (with and without SZIP Library),
modi4 (with SZIP and parallel)
burrwhite (with SZIP and PGI C and Fortran compilers)
Misc. update:
Purpose: Catching up with C library
Description: I added four new functions
h5pset_szip_f
h5pget_filter_by_id_f
h5pmodify_filetr_f
h5pall_filters_avail_f
Solution:
Platforms tested: arabica (with and without SZIP Library),
modi4 (with SZIP and parallel)
burrwhite (with SZIP and PGI C and Fortran compilers)
Misc. update:
Fix
Description:
There are some Fortran compilers which don't have a module flag.
Solution:
If they don't have one, then don't specify it on the line. Also added
the LDFLAGS to the compile line so that we pick up the proper
libraries and their directories.
Platforms tested:
Modi4 (Parallel & Fortran)
Burrwhite (Fortran & C++)
Baldric (Fortran), but make check didn't work because of "libucb.so"
error that I can't fix...)
Misc. update:
Update
Description:
Updated so that the example programs are built with the new h5fc
script after it's installed. (So you need to cd into the examples/
directory and type "make check" or similar. This is how it is in the
C part).
Platforms tested:
Modi4 (Parallel & Fortran)
Burrwhite (Fortran & C++)
Baldric (Fortran), but make check didn't work because of "libucb.so"
error that I can't fix...)
Misc. update:
Update
Description:
Added check for the SZlib option. The SZlib stuff needs to propagate
down to the h5fc script.
Also, removed "examples" from some of the Makefile's rules so that
it's the same as in the C library.
Platforms tested:
Modi4 (Parallel & Fortran)
Burrwhite (Fortran & C++)
Baldric (Fortran), but make check didn't work because of "libucb.so"
error that I can't fix...)
Misc. update:
Bug Fix
Description:
The way to detect modules wasn't in there.
Solution:
Added the 'F9XMODFLAG' variable and have it pointing to the
appropriate place.
Platforms tested:
Arabica. Will test on other platforms one at a time. This won't
affect other parts of the system...
Misc. update:
Bug Fix
Description:
Some of the macros in the script weren't being updated by configure
correctly. Also, the FFLAGS needed to be used during compilation.
Solution:
Put the correct macros in there. Added FFLAGS.
Platforms tested:
Arabica. Only testing it on one platform for now since this is a
script change and needs to be tested on one machine first before
further testing...
Misc. update:
Addition
Description:
Added "h5fc" utility. This is the same as the "h5cc" utility but for
Fortran. It only handles static libraries since that's the only
library we build for Fortran.
Note! I've tested the code on the normal platforms but I haven't
tested the utility itself.
Platforms tested:
Arabica (Fortran)
Modi4 (Fortran & Parallel)
Burrwhite (Fortran & C++
Misc. update:
Update
Description:
The "--enable-parallel=TYPE" option was revamped but the help string
wasn't modified.
Solution:
Modified it to print out just "--enable-parallel" because we no
longer support the "=TYPE" option.
Platforms tested:
arabica (Fortran)
Modi4 (Parallel & Fortran)
Burrwhite (Fortran & C++)
Misc. update:
Bug fix.
Description:
The macro MAX defined here is very commonly defined, e.g., AIX systems.
The compiler did not like duplicated macro defines.
Solution:
H5_MAX is already defined in H5f90.h and used in other code.
Remove MAX and change its use to H5_MAX.
Platforms tested:
"h5committested", plus tested at LLNL Blue.
Misc. update:
Code cleanup
Description:
Adjusted parameters for fortran wrappers of H5Pset_shuffle to match the
changes to the C API function.
Solution:
Platforms tested:
FreeBSD 4.8 (sleipnir) w/szip
Linux 2.4 (sleipnir) w/szip
Solaris 2.7 (arabica) w/FORTRAN
IRIX64 6.5 (modi4) w/szip, FORTRAN & parallel
Misc. update:
Purpose: Maintenance
Description: New fortran APIs h5pset_fapl_multi and h5pget_fapl_multi have been
added along with the new tests.
Solution:
Platforms tested: burrwhite with PGI compilers, arabica and modi4 with
--enable-parallel
Misc. update:
Purpose: Maintenance
Description: New fortran APIs h5pset_fapl_multi and h5pget_fapl_multi have been
added
Solution:
Platforms tested: burrwhite with PGI compilers, arabica and modi4 with
--enable-parallel
Misc. update:
Feature (bug fix)
Description:
Added a new configure file specifically for the IA64 platform
in which ecc and efc are the default compilers.
Also added all the Fortran special setup in the fortran version
Platforms tested:
no h5committest since this is a IA64 platform stuff.
Tested in Titan.
Misc. update:
MANIFEST Updated.
Purpose: Catching up with the C library
Description: Added tests for the follwoing new fortran functions
h5iget_name_f
h5tis_variavle_str_f
h5zunregister_f
h5zfilter_avail_f
h5pset_shuffle_f
h5pset_fletcher32
h5pset_edc_check_f
h5pget_edc_check_f
h5dfill_f
Solution:
Platforms tested: arabica(C and F90), burrwhite (pgcc and pgf90), modi4 (F90 and parallel)
Misc. update:
Purpose: Catching up with the C library
Description: Added the follwoing new fortran functions
h5iget_name_f
h5tis_variavle_str_f
h5zunregister_f
h5zfilter_avail_f
h5pset_shuffle_f
h5pset_fletcher32
h5pset_edc_check_f
h5pget_edc_check_f
h5dfill_f
Solution:
Platforms tested: arabica(C and F90), burrwhite (pgcc and pgf90), modi4 (F90 and parallel)
Misc. update:
Purpose: Catching up with the C library
Description: Added file to provide PGI Fortran support
Solution:
Platforms tested: arabica(C and F90), burrwhite (pgcc and pgf90), modi4 (F90 and parallel)
Misc. update:
Purpose: Catching up with the C library
Description: Enabled checking for shuffle, deflate and checksum filters for Fortran
Solution:
Platforms tested: arabica(C and F90), burrwhite (pgcc and pgf90), modi4 (F90 and parallel)
Misc. update:
Purpose:
Maintenance
Description:
* Added support for generic properties.
* Added support for time allocation properties.
* Added support for variable length datatypes (only datatypes based
on INTEGER, REAL and CHARACTER Fortran types are supported).
* added some missing functions
Solution:
I am checking in new Fortran APIs and their man pages to support
1.5 features listed above.
Not all APIs have tests yet. APIs were written in Fall 2002, and I am afraid
that I will loose the code or totally forget what I did if I wait longer. ;-)
Platforms tested:
arabica (fortran), eirene (fortran), modi4 (parallel, fortran)
Purpose:
Bug fix
Description:
Enumeration datatype was broken in Fortran
Solution:
Fixed C wrapper functions to pass variables correctly from
Fortran to C layer.
Platforms tested:
modi4, arabica, eirene
