I'm wondering if I can get theories on the best way[1] to patch HDF5 1.8.17 to build with nagfor. Namely, my build is dying when it tries to build tf_F03.f90:
make[4]: Entering directory `/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5/fortran/test'
FC tf_F03.lo
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_DP
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_SP
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_I
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_CHR
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_CMPD
[NAG Fortran Compiler pass 1 error termination, 5 errors]
NAG rightly complains (as NAG is wont to do) that SIZEOF does not exist in the Fortran Standard (2003 or otherwise). There is storage_size() in F2008 and a colleague suggested:
#ifdef NAGFOR
integer function sizeof(a)
class(*), intent(in) :: a
sizeof = storage_size(a) / 8 ! bits -> bytes
end function sizeof #endif
and it allows it to compile.
Would this be my best bet? Or is there a better way that the HDF5 1.10 transition indicated?
Matt
[1] Note: looking at HDF5 1.10.0-patch1, the "correct" answer is probably move to HDF5 1.10 as that seems to have revamped all the fortran/test bits. But, I really don't want to have to deal with the 1.8=>1.10 transition at the moment. My limited testing seems to show it might be a non-issue as I use netCDF4 only, but others use these libraries to handle pure HDF5 files and I have not tested for side effects everywhere. So, for now, I'm dealing with HDF5 1.8.17.
···
--
Matt Thompson, SSAI, Sr Scientific Programmer/Analyst
NASA GSFC, Global Modeling and Assimilation Office
Code 610.1, 8800 Greenbelt Rd, Greenbelt, MD 20771
Phone: 301-614-6712 Fax: 301-614-6246 http://science.gsfc.nasa.gov/sed/bio/matthew.thompson
Also, we don’t have access to a NAG compiler, so if you can compile 1.8, run the fortran tests (i.e. in the fortran directory, issue “make check”), and report back any issues then that would be great.
If you can do the same for 1.10, it would be appreciated,
On Aug 16, 2016, at 12:52 PM, Thompson, Matt (GSFC-610.1)[SCIENCE SYSTEMS AND APPLICATIONS INC] <matthew.thompson@nasa.gov<mailto:matthew.thompson@nasa.gov>> wrote:
All,
I'm wondering if I can get theories on the best way[1] to patch HDF5 1.8.17 to build with nagfor. Namely, my build is dying when it tries to build tf_F03.f90:
make[4]: Entering directory `/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5/fortran/test'
FC tf_F03.lo
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_DP
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_SP
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_I
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_CHR
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_CMPD
[NAG Fortran Compiler pass 1 error termination, 5 errors]
NAG rightly complains (as NAG is wont to do) that SIZEOF does not exist in the Fortran Standard (2003 or otherwise). There is storage_size() in F2008 and a colleague suggested:
#ifdef NAGFOR
integer function sizeof(a)
class(*), intent(in) :: a
sizeof = storage_size(a) / 8 ! bits -> bytes
end function sizeof #endif
and it allows it to compile.
Would this be my best bet? Or is there a better way that the HDF5 1.10 transition indicated?
Matt
[1] Note: looking at HDF5 1.10.0-patch1, the "correct" answer is probably move to HDF5 1.10 as that seems to have revamped all the fortran/test bits. But, I really don't want to have to deal with the 1.8=>1.10 transition at the moment. My limited testing seems to show it might be a non-issue as I use netCDF4 only, but others use these libraries to handle pure HDF5 files and I have not tested for side effects everywhere. So, for now, I'm dealing with HDF5 1.8.17.
--
Matt Thompson, SSAI, Sr Scientific Programmer/Analyst
NASA GSFC, Global Modeling and Assimilation Office
Code 610.1, 8800 Greenbelt Rd, Greenbelt, MD 20771
Phone: 301-614-6712 Fax: 301-614-6246
Also, we don�t have access to a NAG compiler, so if you can compile 1.8,
run the fortran tests (i.e. in the fortran directory, issue �make
check�), and report back any issues then that would be great.
Scot,
Well, my HDF5 (hacked-1.8.17) built (huzzah!) so I went into fortran/test and did a make check and it liked the old-style Fortran, but F2003 had its issues (see attached) and it dumped core.
I'm not sure how to be more verbose than what it is, but you might be able to figure out if the tests are dying where my hack was inserted.
If you can do the same for 1.10, it would be appreciated,
Also, we don�t have access to a NAG compiler, so if you can compile 1.8,
run the fortran tests (i.e. in the fortran directory, issue �make
check�), and report back any issues then that would be great.
Scot,
I downloaded the 1.8 SVN and ran into the same issue:
make[4]: Entering directory `/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5-1.8-svn/fortran/test'
FC tf_F03.lo
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_DP
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_SP
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_I
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_CHR
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_CMPD
[NAG Fortran Compiler pass 1 error termination, 5 errors]
It looks to me like the SVN tf_F03.f90 is identical to that in 1.8.17. So this is expected, I suppose.
I then tried the 1.10 SVN:
If you can do the same for 1.10, it would be appreciated,
It took a bit as our build system assumes a configure will exist, so I got to go on a tour of GNU to update all my autotools, etc. to get autogen.sh to build something. But, I got to it and, interestingly, it died in fortran/ but before NAG had a chance to strut its stuff:
Making all in src
make[1]: Entering directory `/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5-1.10-trunk/fortran/src'
CC H5match_types.o
H5match_types.c: In function �main�:
H5match_types.c:163:7: warning: unused variable �found_long_double� [-Wunused-variable]
int found_long_double = 0;
^~~~~~~~~~~~~~~~~
CCLD H5match_types
./H5match_types
Error: couldn't find a size for real_f
make[1]: *** [H5f90i_gen.h] Error 255
make[1]: Leaving directory `/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5-1.10-trunk/fortran/src'
make: *** [all-recursive] Error 1
This is building with NAG 6.0 and GCC 6.1 so:
CC => mpicc => GCC 6.1 with Open MPI 1.10.0
Matt
···
On 08/16/2016 02:33 PM, Scot Breitenfeld wrote:
--
Matt Thompson, SSAI, Sr Scientific Programmer/Analyst
NASA GSFC, Global Modeling and Assimilation Office
Code 610.1, 8800 Greenbelt Rd, Greenbelt, MD 20771
Phone: 301-614-6712 Fax: 301-614-6246 http://science.gsfc.nasa.gov/sed/bio/matthew.thompson
Also, we don’t have access to a NAG compiler, so if you can compile 1.8,
run the fortran tests (i.e. in the fortran directory, issue “make
check”), and report back any issues then that would be great.
Scot,
I downloaded the 1.8 SVN and ran into the same issue:
make[4]: Entering directory `/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5-1.8-svn/fortran/test'
FC tf_F03.lo
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_DP
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_SP
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_I
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_CHR
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_CMPD
[NAG Fortran Compiler pass 1 error termination, 5 errors]
It looks to me like the SVN tf_F03.f90 is identical to that in 1.8.17. So this is expected, I suppose.
I’m sorry, I did not update the Makefile.in, it should now compile tf_F08.F90 instead.
I then tried the 1.10 SVN:
If you can do the same for 1.10, it would be appreciated,
It took a bit as our build system assumes a configure will exist, so I got to go on a tour of GNU to update all my autotools, etc. to get autogen.sh to build something. But, I got to it and, interestingly, it died in fortran/ but before NAG had a chance to strut its stuff:
Making all in src
make[1]: Entering directory `/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5-1.10-trunk/fortran/src'
CC H5match_types.o
H5match_types.c: In function ‘main’:
H5match_types.c:163:7: warning: unused variable ‘found_long_double’ [-Wunused-variable]
int found_long_double = 0;
^~~~~~~~~~~~~~~~~
CCLD H5match_types
./H5match_types
Error: couldn't find a size for real_f
make[1]: *** [H5f90i_gen.h] Error 255
make[1]: Leaving directory `/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5-1.10-trunk/fortran/src'
make: *** [all-recursive] Error 1
I think I fixed the issue in trunk, can you try it again? If that does not work then can you send the config.log file. I would be interested in the lines of output from configure:
checking if Fortran compiler supports intrinsic SIZEOF... yes
checking if Fortran compiler supports intrinsic C_SIZEOF... yes
checking if Fortran compiler supports intrinsic STORAGE_SIZE... yes
checking if Fortran compiler supports intrinsic module ISO_FORTRAN_ENV... yes
checking for Fortran INTEGER KINDs... {1,2,4,8,16}
checking for Fortran REAL KINDs... {4,8,10,16}
checking for Fortran REALs maximum decimal precision... 33
checking sizeof of native KINDS...
checking for Fortran INTEGER KINDs... {1,2,4,8,16}
checking for Fortran REAL KINDs... {4,8,10,16}
checking for Fortran REALs maximum decimal precision... 33
checking sizeof of available INTEGER KINDs... {1,2,4,8,16}
checking sizeof of available REAL KINDs... {4,8,16,16}
checking if Fortran compiler supports intrinsic C_LONG_DOUBLE... yes
checking if Fortran C_LONG_DOUBLE is different from C_DOUBLE... yes
checking for Fortran interoperable KINDS with C... {4,8,10,16}
checking whether we are using the GNU C++ compiler… yes
Thanks for taking the time doing this,
Scot
BTW, you can find a script at
which will automatically download and install (locally) all the packages needed to successfully run autogen.sh.
Also, we don�t have access to a NAG compiler, so if you can compile 1.8,
run the fortran tests (i.e. in the fortran directory, issue �make
check�), and report back any issues then that would be great.
Scot,
I downloaded the 1.8 SVN and ran into the same issue:
make[4]: Entering directory
`/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5-1.8-svn/fortran/test'
FC tf_F03.lo
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_DP
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_SP
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_I
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_CHR
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_CMPD
[NAG Fortran Compiler pass 1 error termination, 5 errors]
It looks to me like the SVN tf_F03.f90 is identical to that in 1.8.17.
So this is expected, I suppose.
I�m sorry, I did not update the Makefile.in, it should now compile
tf_F08.F90 instead.
I did an 'svn update' and, huzzah!, it built. It still dies in the same place in the tests though:
Runtime Error: Invalid edit descriptor for integer i/o-list item
Program terminated by I/O error on internal file
==============================
FORTRAN 2003 tests
==============================
FORTRANLIB_TEST is linked with HDF5 Library version 1.8 release 18
Testing 1-D Array of Compound Datatypes Functionality PASSED
Testing 1-D Array of Compound Array Datatypes Functionality PASSED
Testing 3-D array by dataset, using C_LOC PASSED
Testing writing/reading enum dataset, using C_LOC PASSED
Testing enumeration conversions PASSED
Testing writing/reading bitfield dataset, using C_LOC PASSED
Testing writing/reading opaque datatypes, using C_LOC PASSED
Testing writing/reading object references, using C_LOC PASSED
Testing writing/reading region references, using C_LOC PASSED
Testing writing/reading variable-length datatypes, using C_LOC PASSED
Testing writing/reading variable-string datatypes, using C_LOC PASSED
Testing variable-string write/read, using h5dwrite_f/h5dread_f PASSED
Testing writing/reading string datatypes, using C_LOC PASSED
Command terminated by signal 6
0.01user 0.01system 0:00.04elapsed 52%CPU (0avgtext+0avgdata 7380maxresident)k
0inputs+0outputs (0major+5953minor)pagefaults 0swaps
make[4]: *** [fortranlib_test_F03.chkexe_] Error 1
****** 1.10 ******
I think I fixed the issue in trunk, can you try it again? If that does
not work then can you send the config.log file. I would be interested in
the lines of output from configure:
checking if Fortran compiler supports intrinsic SIZEOF... yes
checking if Fortran compiler supports intrinsic C_SIZEOF... yes
checking if Fortran compiler supports intrinsic STORAGE_SIZE... yes
checking if Fortran compiler supports intrinsic module
ISO_FORTRAN_ENV... yes
checking for Fortran INTEGER KINDs... {1,2,4,8,16}
checking for Fortran REAL KINDs... {4,8,10,16}
checking for Fortran REALs maximum decimal precision... 33
checking sizeof of native KINDS...
checking for Fortran INTEGER KINDs... {1,2,4,8,16}
checking for Fortran REAL KINDs... {4,8,10,16}
checking for Fortran REALs maximum decimal precision... 33
checking sizeof of available INTEGER KINDs... {1,2,4,8,16}
checking sizeof of available REAL KINDs... {4,8,16,16}
checking if Fortran compiler supports intrinsic C_LONG_DOUBLE... yes
checking if Fortran C_LONG_DOUBLE is different from C_DOUBLE... yes
checking for Fortran interoperable KINDS with C... {4,8,10,16}
checking whether we are using the GNU C++ compiler� yes
Well, it died again, but slightly differently:
make[4]: Entering directory `/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5-1.10-trunk/fortran/src'
CC H5match_types.o
H5match_types.c: In function �main�:
H5match_types.c:163:7: warning: unused variable �found_long_double� [-Wunused-variable]
int found_long_double = 0;
^~~~~~~~~~~~~~~~~
CCLD H5match_types
./H5match_types
make install-am
make[5]: Entering directory `/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5-1.10-trunk/fortran/src'
PPFC H5fortran_types.lo
libtool: compile: mpifort -I. -I../../src -I../../src -I../../fortran/src -fpp -mismatch_all -c H5fortran_types.F90 -o H5fortran_types.o
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
[NAG Fortran Compiler normal termination]
PPFC H5f90global.lo
libtool: compile: mpifort -I. -I../../src -I../../src -I../../fortran/src -fpp -mismatch_all -c H5f90global.F90 -o H5f90global.o
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
[NAG Fortran Compiler normal termination]
PPFC H5_ff.lo
libtool: compile: mpifort -I. -I../../src -I../../src -I../../fortran/src -fpp -mismatch_all -c H5_ff.F90 -o H5_ff.o
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
Error: H5_ff.F90, line 396: Implicit type for FORTRAN_INTEGER_8
detected at FORTRAN_INTEGER_8@)
Warning: H5_ff.F90, line 424: Symbol FORTRAN_INTEGER_8 referenced but never set
[NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning]
make[5]: *** [H5_ff.lo] Error 1
Perhaps this is due to NAG's weirdness (kind(0.0d0) is 2, not 8). Here is the bit of the configure run, and find attached the config.log:
checking if Fortran compiler supports intrinsic SIZEOF... no
checking if Fortran compiler supports intrinsic C_SIZEOF... no
checking if Fortran compiler supports intrinsic STORAGE_SIZE... yes
checking if Fortran compiler supports intrinsic module ISO_FORTRAN_ENV... yes
checking for Fortran INTEGER KINDs... {1,2,3,4}
checking for Fortran REAL KINDs... {1,2,3}
checking for Fortran REALs maximum decimal precision... 31
checking sizeof of native KINDS...
checking for Fortran INTEGER KINDs... {1,2,3,4}
checking for Fortran REAL KINDs... {1,2,3}
checking for Fortran REALs maximum decimal precision... 31
checking sizeof of available INTEGER KINDs... {1,2,4,8}
checking sizeof of available REAL KINDs... {4,8,16}
checking if Fortran compiler supports intrinsic C_LONG_DOUBLE... no
checking if Fortran C_LONG_DOUBLE is different from C_DOUBLE... no
checking for Fortran interoperable KINDS with C... {1,2,3}
checking whether we are using the GNU C++ compiler... yes
On Aug 18, 2016, at 11:01 AM, Thompson, Matt (GSFC-610.1)[SCIENCE >> SYSTEMS AND APPLICATIONS INC] <matthew.thompson@nasa.gov >> <mailto:matthew.thompson@nasa.gov>> wrote:
On 08/16/2016 02:33 PM, Scot Breitenfeld wrote:
--
Matt Thompson, SSAI, Sr Scientific Programmer/Analyst
NASA GSFC, Global Modeling and Assimilation Office
Code 610.1, 8800 Greenbelt Rd, Greenbelt, MD 20771
Phone: 301-614-6712 Fax: 301-614-6246
Also, we don’t have access to a NAG compiler, so if you can compile 1.8,
run the fortran tests (i.e. in the fortran directory, issue “make
check”), and report back any issues then that would be great.
Scot,
I downloaded the 1.8 SVN and ran into the same issue:
make[4]: Entering directory
`/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5-1.8-svn/fortran/test'
FC tf_F03.lo
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_DP
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_SP
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_I
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_CHR
Error: tf_F03.f90, line 128: Implicit type for SIZEOF in H5_SIZEOF_CMPD
[NAG Fortran Compiler pass 1 error termination, 5 errors]
It looks to me like the SVN tf_F03.f90 is identical to that in 1.8.17.
So this is expected, I suppose.
I’m sorry, I did not update the Makefile.in, it should now compile
tf_F08.F90 instead.
I did an 'svn update' and, huzzah!, it built. It still dies in the same place in the tests though:
Runtime Error: Invalid edit descriptor for integer i/o-list item
Program terminated by I/O error on internal file
==============================
FORTRAN 2003 tests
==============================
FORTRANLIB_TEST is linked with HDF5 Library version 1.8 release 18
Testing 1-D Array of Compound Datatypes Functionality PASSED
Testing 1-D Array of Compound Array Datatypes Functionality PASSED
Testing 3-D array by dataset, using C_LOC PASSED
Testing writing/reading enum dataset, using C_LOC PASSED
Testing enumeration conversions PASSED
Testing writing/reading bitfield dataset, using C_LOC PASSED
Testing writing/reading opaque datatypes, using C_LOC PASSED
Testing writing/reading object references, using C_LOC PASSED
Testing writing/reading region references, using C_LOC PASSED
Testing writing/reading variable-length datatypes, using C_LOC PASSED
Testing writing/reading variable-string datatypes, using C_LOC PASSED
Testing variable-string write/read, using h5dwrite_f/h5dread_f PASSED
Testing writing/reading string datatypes, using C_LOC PASSED
Command terminated by signal 6
0.01user 0.01system 0:00.04elapsed 52%CPU (0avgtext+0avgdata 7380maxresident)k
0inputs+0outputs (0major+5953minor)pagefaults 0swaps
make[4]: *** [fortranlib_test_F03.chkexe_] Error 1
Some progress, I would need to know the line where this fails.
****** 1.10 ******
I think I fixed the issue in trunk, can you try it again? If that does
not work then can you send the config.log file. I would be interested in
the lines of output from configure:
checking if Fortran compiler supports intrinsic SIZEOF... yes
checking if Fortran compiler supports intrinsic C_SIZEOF... yes
checking if Fortran compiler supports intrinsic STORAGE_SIZE... yes
checking if Fortran compiler supports intrinsic module
ISO_FORTRAN_ENV... yes
checking for Fortran INTEGER KINDs... {1,2,4,8,16}
checking for Fortran REAL KINDs... {4,8,10,16}
checking for Fortran REALs maximum decimal precision... 33
checking sizeof of native KINDS...
checking for Fortran INTEGER KINDs... {1,2,4,8,16}
checking for Fortran REAL KINDs... {4,8,10,16}
checking for Fortran REALs maximum decimal precision... 33
checking sizeof of available INTEGER KINDs... {1,2,4,8,16}
checking sizeof of available REAL KINDs... {4,8,16,16}
checking if Fortran compiler supports intrinsic C_LONG_DOUBLE... yes
checking if Fortran C_LONG_DOUBLE is different from C_DOUBLE... yes
checking for Fortran interoperable KINDS with C... {4,8,10,16}
checking whether we are using the GNU C++ compiler… yes
Well, it died again, but slightly differently:
make[4]: Entering directory `/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5-1.10-trunk/fortran/src'
CC H5match_types.o
H5match_types.c: In function ‘main’:
H5match_types.c:163:7: warning: unused variable ‘found_long_double’ [-Wunused-variable]
int found_long_double = 0;
^~~~~~~~~~~~~~~~~
CCLD H5match_types
./H5match_types
make install-am
make[5]: Entering directory `/gpfsm/dswdev/mathomp4/Baselibs/TmpBaselibs/GMAO-Baselibs-5_0_2-NAG/src/hdf5-1.10-trunk/fortran/src'
PPFC H5fortran_types.lo
libtool: compile: mpifort -I. -I../../src -I../../src -I../../fortran/src -fpp -mismatch_all -c H5fortran_types.F90 -o H5fortran_types.o
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
[NAG Fortran Compiler normal termination]
PPFC H5f90global.lo
libtool: compile: mpifort -I. -I../../src -I../../src -I../../fortran/src -fpp -mismatch_all -c H5f90global.F90 -o H5f90global.o
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
[NAG Fortran Compiler normal termination]
PPFC H5_ff.lo
libtool: compile: mpifort -I. -I../../src -I../../src -I../../fortran/src -fpp -mismatch_all -c H5_ff.F90 -o H5_ff.o
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
Error: H5_ff.F90, line 396: Implicit type for FORTRAN_INTEGER_8
detected at FORTRAN_INTEGER_8@)
Warning: H5_ff.F90, line 424: Symbol FORTRAN_INTEGER_8 referenced but never set
[NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning]
make[5]: *** [H5_ff.lo] Error 1
Perhaps this is due to NAG's weirdness (kind(0.0d0) is 2, not 8). Here is the bit of the configure run, and find attached the config.log:
We tried to avoid the non-standard assumption that KIND = SIZEOF, but obviously this is still an issue. Unfortunately, this is a little more involved than just changing a couple lines of code. I will enter a bug report new bug report, as the old one addressed just the sizeof issue, and hopefully it will be fixed in the next release. I will try to find a NAG compiler to debug the issues in 1.8 and 1.10.
Thanks,
Scot
···
On Aug 19, 2016, at 8:11 AM, Thompson, Matt (GSFC-610.1)[SCIENCE SYSTEMS AND APPLICATIONS INC] <matthew.thompson@nasa.gov> wrote:
On 08/18/2016 02:35 PM, Scot Breitenfeld wrote:
From: "Scot Breitenfeld" <brtnfld@hdfgroup.org>
To: "HDF Users Discussion List" <hdf-forum@lists.hdfgroup.org>
Sent: Friday, 19 August, 2016 16:31:06
Subject: Re: [Hdf-forum] Best Way to Patch HDF5 1.8.17 to compile with nagfor
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
Error: H5_ff.F90, line 396: Implicit type for FORTRAN_INTEGER_8
detected at FORTRAN_INTEGER_8@)
Warning: H5_ff.F90, line 424: Symbol FORTRAN_INTEGER_8 referenced but never set
[NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning]
make[5]: *** [H5_ff.lo] Error 1
Perhaps this is due to NAG's weirdness (kind(0.0d0) is 2, not 8). Here is the
bit of the configure run, and find attached the config.log:
just in case: "NAG's weirdness" is optional. Adding "-kind=byte" to FCFLAG switches from "sequentiell" to "byte" enumeration. make check will still fail though.
Regards, Frank.
PS:
v1.10 (svn, patch1) won't compile with nagfor6.1. gcc4.8.5 and "-kind=byte" ...
Error: tH5T_F03.F90, line 1178: C_LOC array argument is REAL(KIND=16), this kind type parameter is not interoperable
Apart from that, Makefiles contain
$(PPFCCOMPILE) -c -o $@ $(FCFLAGS)
$(PPFCCOMPILE) contains already $(FCFLAGS), so duplicates flags. nagfor would refuse duplicate "-kind" flags.
We think all the issues with HDF5 and NAG were resolved for both 1.8 and 1.10. All the fixes are currently in the hdf5_1_8 branch and the 'develop' branch and will be included in the next releases. If you have any further issues, please feel free to report them back to us.
From: "Scot Breitenfeld" <brtnfld@hdfgroup.org>
To: "HDF Users Discussion List" <hdf-forum@lists.hdfgroup.org>
Sent: Friday, 19 August, 2016 16:31:06
Subject: Re: [Hdf-forum] Best Way to Patch HDF5 1.8.17 to compile with nagfor
NAG Fortran Compiler Release 6.0(Hibiya) Build 1064
Error: H5_ff.F90, line 396: Implicit type for FORTRAN_INTEGER_8
detected at FORTRAN_INTEGER_8@)
Warning: H5_ff.F90, line 424: Symbol FORTRAN_INTEGER_8 referenced but never set
[NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning]
make[5]: *** [H5_ff.lo] Error 1
Perhaps this is due to NAG's weirdness (kind(0.0d0) is 2, not 8). Here is the
bit of the configure run, and find attached the config.log:
just in case: "NAG's weirdness" is optional. Adding "-kind=byte" to FCFLAG switches from "sequentiell" to "byte" enumeration. make check will still fail though.
Regards, Frank.
PS:
v1.10 (svn, patch1) won't compile with nagfor6.1. gcc4.8.5 and "-kind=byte" ...
Error: tH5T_F03.F90, line 1178: C_LOC array argument is REAL(KIND=16), this kind type parameter is not interoperable
Apart from that, Makefiles contain
$(PPFCCOMPILE) -c -o $@ $(FCFLAGS)
$(PPFCCOMPILE) contains already $(FCFLAGS), so duplicates flags. nagfor would refuse duplicate "-kind" flags.
