HDF version 4.2.14 released on 2018-06-26 ==================================================== INTRODUCTION This document describes the differences between this release and the HDF 4.2.13 release. It is written for people who are familiar with previous releases of HDF and wish to migrate to this version of HDF. Note that the HDF4 documentation will be updated at the time of each final release and can be found on the HDF4 support page at: https://portal.hdfgroup.org/display/HDF4/HDF4 The official HDF4 releases can be obtained from: https://portal.hdfgroup.org/display/support/Download+HDF4 If you have any questions or comments, please send them to the HDF Help Desk: help@hdfgroup.org CONTENTS - New features and changes -- Configuration - Support for new platforms and compilers - Bugs fixed since HDF 4.2.13 -- Configuration -- Library -- Utilities - Documentation - Platforms tested - Known problems New features and changes ======================== Configuration: ------------- - CMake Refactor use of CMAKE_BUILD_TYPE for new variable, which understands the type of generator in use. Added new configuration macros to use new HDF_BUILD_TYPE variable. This variable is set correctly for the type of generator being used for the build. Changes follow from hdf5. (ADB - 2018/01/08, HDFFV-10385, HDFFV-10296) - XDR glibc stopped installing rpc headers by default back in 2011: versions 2.14 and 2.15 never install them, versions 2.16 and higher require the configuration option --enable-obsolete-rpc. Most distros still install the headers for backwards compatibility, but Fedora 28 has now stopped support. The preferred library is libtirpc. On Fedora 28, install the libtirpc-devel package. (ADB - 2018/05/29, HDFFR-1568) Support for new platforms and compilers ======================================= Bugs fixed since HDF 4.2.13 =========================== Configuration: ------------- - CMake Update CMake commands configuration. A number of improvements were made to the CMake commands. Most changes simplify usage or eliminate unused constructs. Also, some changes support better cross-platform support. Changes follow from hdf5. (ADB - 2018/02/01, HDFFV-10398) - CMake Correct usage of CMAKE_BUILD_TYPE variable. The use of the CMAKE_BUILD_TYPE is incorrect for multi-config generators (Visual Studio and XCode) and is optional for single config generators. Created a new macro to check GLOBAL PROPERTY -> GENERATOR_IS_MULTI_CONFIG Created two new HDF variable, HDF_BUILD_TYPE and HDF_CFG_BUILD_TYPE. Defaults for these variables is "Release". Changes follow from hdf5. Library: -------- - Removal of a memory leak HTPendaccess was missing from HRPendaccess and resulting in a memory leak. This is now fixed. (BMR - 2018/06/18, HDFFR-1560) - Fortran Changed array data constructor to be g77 compatible. Updated INSTALL notes about FFLAGS for g77. (MSB - 2018/05/23, HDFFR-1553) - Java JNI functions called routine with wrong interface. GRsetchunk, GRsetchunkcache changed from SD in hdfgrImp.c. SDfileinfo changed from SD in hdfsdsImp.c. (ADB - 2018/05/29, HDFFR-1565) - Java JNI functions used wrong constants. MAX_VAR_DIMS and MAX_NC_NAME should have been H4_MAX_VAR_DIMS and H4_MAX_NC_NAME. MAX_VAR_DIMS used in Java source is assigned the H4_MAX_VAR_DIMS value. (ADB - 2018/05/29, HDFFR-1563) Documentation ============= - Various minor improvements are made to the User's Guide and Reference Manual. (BMR - 2018/06/26) Platforms tested ================ This version has been tested in the following platforms: (Format: uname -s, uname -r uname -v, uname -p, uname -m) Linux 2.6.32-573.22.1.el6.x86_64 gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16) #1 SMP, x86_64 GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16) (mayll/platypus) icc (ICC) 17.0.0.098 Build 20160721 ifort (IFORT) 17.0.0.098 Build 20160721 pgcc and pgf90 17.10-0 64-bit target on x86-64 Linux -tp nehalem Linux, 3.10.0-327.10.1.el7.x86_64 gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4) #1 SMP x86_64, GNU/Linux GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4) (jelly/moohan) icc (ICC) 17.0.0.098 Build 20160721 ifort (IFORT) 17.0.0.098 Build 20160721 pgcc and pgf90 17.10-0 64-bit target on x86-64 Linux -tp haswell Linux, 2.6.32-573.18.1.el6.ppc64 gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18) #1 SMP, ppc64 (ostrich) (1) GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) (2) IBM XL Fortran for Linux, V15.1 (64-bit mode) SunOS 5.11 (32- and 64-bit) Sun C 5.12 SunOS_sparc 2011/11/16 11.1, sparc, sun4v (emu) Sun Fortran 95 8.6 SunOS_sparc 2011/11/16 Windows 7 Visual Studio 2012 w/ Intel Fortran 15 (cmake) Visual Studio 2013 w/ Intel Fortran 15 (cmake) Visual Studio 2015 w/ Intel Fortran 16 (cmake) Windows 7 x64 Visual Studio 2012 w/ Intel Fortran 15 (cmake) Visual Studio 2013 w/ Intel Fortran 15 (cmake) Visual Studio 2015 w/ Intel Fortran 16 (cmake) Visual Studio 2015 w/ Intel C, Fortran 2017 (cmake) Windows 10 Visual Studio 2015 w/ Intel Fortran 16 (cmake) Cygwin(CYGWIN_NT-6.1 2.8.0(0.309/5/3) gcc and gfortran compilers (GCC 5.4.0) (cmake and autotools) Windows 10 x64 Visual Studio 2015 w/ Intel Fortran 16 (cmake) Mac OS X 10.10.5, Darwin, 14.5.0 Apple clang version 6.1 from Xcode 7.0 x86_64 gfortran GNU Fortran (GCC) 4.9.2 (osx1010dev) Intel icc and ifort version 15.0.3 Mac OS X 10.11.5, Darwin, 15.6.0 Apple clang version 7.3 from Xcode 7.3 x86_64 gfortran GNU Fortran (GCC) 5.2.0 (osx1010dev) Intel icc and ifort version 15.0.3 macOS Sierra 10.12.5, Darwin, Apple clang version 8.1.0 from Xcode 8.3 16.6.0, x86_64 gfortran GNU Fortran (GCC) 7.1.0 (kite) Intel icc and ifort version 17.0.2 Debian 8.6.0 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2, x86_64 GNU/Linux gcc (Debian 4.9.2-10) 4.9.2 GNU Fortran (Debian 4.9.2-10) 4.9.2 (cmake and autotools) Fedora24 4.7.2-201.fc24.x86_64 #1 SMP x86_64 GNU/Linux gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3) GNU Fortran (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3) (cmake and autotools) Ubuntu 16.04.1 4.4.0-38-generic #57-Ubuntu SMP x86_64 GNU/Linux gcc (Ubuntu 5.4.0-6ubuntu16.04.4) 5.4.0 GNU Fortran (Ubuntu 5.4.0-6ubuntu16.04.4) 5.4.0 (cmake and autotools) Known problems ============== o Several Fortran examples print "^@" when displaying strings (for example, names of the attributes). This happens because Fortran application doesn't know the length of the strings passed from the C library. EIP - 2015-01-11, HDFFR-1477 o CMake fails to set the full path to the install location on Windows: The configuration file for examples, HDF4_Examples.cmake, must be updated with the correct value by editing the file or using the INSTALLDIR option. This issue is because of spaces in the path. ADB - 2014/02/03 o CMake "make install" fails installing the tools: Use CPack to create an install package. ADB - 2014/02/03 o CMake does not install these man pages: hdf.1, ncdump.1, ncgen.1 AKC/BMR - 2014/02/02 o For Mac OS X 10.7 Lion, 10.8 Mountain Lion, 10.9 Mavericks, 10.10 Yosemite, and 10.11 El Capitan, when compiling with -O2, some xdr functions might cause memory corruption. This happened for GCC, Intel and Clang compilers. Currently, -O0 level optimization is used to avoid this problem. (HDFFR-1318,1327,1358,1425) EIP - 2013/02/05, BMR - 2016/06/24 o On IBM PowerPC 64, hdftest fails when gcc 4.4.6 is used with -O3 optimization level. o When building in AIX systems, if CC is xlc with -qlanglvl=ansi, configure will fail when checking for the jpeglib.h header due to the duplicated macro definition of HAVE_STDLIB_H. This is because some newer builds of the jpeg library have HAVE_STDLIB_H defined in the jconfig.h header file. Without the -qlanglvl=ansi, some older xlc versions (e.g., V7.0) still fail, but newer xlc versions (e.g., V9.0) pass. AKC - 2010/02/17 o When building on Linux/UNIX platforms, the szip shared library files must be in the system library path. This can be done by adding a link to the libsz.* files in the /usr/lib folder or by adding the library location to the LD_LIBRARY_PATH environment variable. Ex. export LD_LIBRARY_PATH=path_to_szip_lib:$LD_LIBRARY_PATH Optionally, one can use the static szip library files by adding '-static' to the CFLAGS environment variable. o Existing data written by an HDF4 Library prior to HDF 4.2r2: When a one-dimensional SDS and a dimension scale have the same name, subsequent accesses to the dimension scale or to the SDS might produce undesired results because the libraries could not distinguish between the two objects. In the case of writing, data might even be corrupted. For example, SDS data might be written to a dimension variable or vice versa. (bugzilla #624) HDF4 Library Releases 4.2r2 and later make a distinction between an SDS and a dimension variable. However, as with older versions, these recent versions are unable to detect such conflicts in files created by earlier releases. It is therefore STRONGLY recommended to check for such name duplication before working with data created with a pre-4.2r2 library. The functions SDgetnumvars_byname and SDnametoindices are provided to help detect such name conflicts and select the correct object to access, respectively; see the HDF Reference Manual entries for further details. FB - 2009/01/26 BMR - revised 2011/06/24 o N-bit compression is not supported with Fortran APIs. o Using both fill-value and compression on SD datasets does not work. o When using PGI compilers, make sure that the JPEG library is also compiled with a PGI C compiler; linking with a JPEG library built with gcc causes JPEG library tests to fail. To bypass the problem: x Set LIBS flag to $PGI_JPEG_INSTALL_DIR/lib/libjpeg.a where $PGI_JPEG_INSTALL_DIR points to the installation directory for the PGI-compiled JPEG library: setenv LIBS $PGI_JPEG_INSTALL_DIR/lib/libjpeg.a x Use the --with-jpeg=$PGI_JPEG_INSTALL_DIR configure flag to configure with the PGI-compiled JPEG library: ./configure --with-jpeg=$PGI_JPEG_INSTALL_DIR --with-zlib.... o In order for the API SDgetdatasize to get the correct compressed size of the data, the dataset needs to be closed (SDendaccess) or read (SDreaddata) after being written and before SDgetdatasize is called. BMR - 2008/11/22