When I try a Java test program that first loads zlib1.dll, then szlibdll.dll and finally hdf5dll.dll, it doesn't work in version 1.8.4 (patch 1) even though it works with a hdf5dll.dll of version 1.8.2.
With 1.8.4 (patch 1) the resulting exception conveyed a message like this:
(path+)"hdf5dll.dll: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem"
The platform is Windows XP (32-bit). The library (hdf5dll.dll v1.8.4) originates from downloaded package hdf5-1.8.4-patch1-32bit-vs2005-ivf91.zip . The hdf5dll.dll of version 1.8.2 originates from package 5-182-win-vs2005.zip (downloaded about a year ago).
I compared the INSTALL_Windows.txt and README.txt files in those packages with a diffing tool and there seem to be no differences in required DLLs or other configurations. And both DLLs seem to be compiled with the same version of VS.
The first thing that might be the problem is the call to H5.H5check_version() is failing.
A couple of questions, are you using the pre-built hdf-java or did you build from source.
Also, what version of hdf-java are you using?
Allen
···
Hi,
When I try a Java test program that first loads zlib1.dll, then szlibdll.dll and finally hdf5dll.dll, it doesn't work in version 1.8.4 (patch 1) even though it works with a hdf5dll.dll of version 1.8.2.
With 1.8.4 (patch 1) the resulting exception conveyed a message like this:
(path+)"hdf5dll.dll: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem"
The platform is Windows XP (32-bit). The library (hdf5dll.dll v1.8.4) originates from downloaded package hdf5-1.8.4-patch1-32bit-vs2005-ivf91.zip . The hdf5dll.dll of version 1.8.2 originates from package 5-182-win-vs2005.zip (downloaded about a year ago).
I compared the INSTALL_Windows.txt and README.txt files in those packages with a diffing tool and there seem to be no differences in required DLLs or other configurations. And both DLLs seem to be compiled with the same version of VS.
Thanks. However, it turned out that this problem wasn't essentially a Java issue but could be replicated by C/C++ code that tries to load hdf5dll.dll:
The version 1.8.4p1 of hdf5dll.dll depends on MSVCR80.DLL (which can be downloaded in a VS 2005 redistributables package) but there was some other problem that prevented loading hdf5dll.dll. The dependency walker depends.exe reported that the Side-by-Side configuration information of hdf5dll.dll contains errors. I've reported this to the Helpdesk.
Best Regards,
Vesa Paatero
BiolinScientific
···
-----Original Message-----
From: Allen D Byrne [mailto:byrn@hdfgroup.org]
Sent: 8. maaliskuuta 2010 19:16
To: hdf-forum@hdfgroup.org
Cc: Vesa Paatero
Subject: Re: [Hdf-forum] Problem loading hdf5dll.dll in v1.8.4 (patch 1) while v1.8.2 works.
Vesa,
The first thing that might be the problem is the call to H5.H5check_version() is failing.
A couple of questions, are you using the pre-built hdf-java or did you build from source.
Also, what version of hdf-java are you using?
Allen
Hi,
When I try a Java test program that first loads zlib1.dll, then szlibdll.dll and finally hdf5dll.dll, it doesn't work in version 1.8.4 (patch 1) even though it works with a hdf5dll.dll of version 1.8.2.
With 1.8.4 (patch 1) the resulting exception conveyed a message like this:
(path+)"hdf5dll.dll: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem"
The platform is Windows XP (32-bit). The library (hdf5dll.dll v1.8.4) originates from downloaded package hdf5-1.8.4-patch1-32bit-vs2005-ivf91.zip . The hdf5dll.dll of version 1.8.2 originates from package 5-182-win-vs2005.zip (downloaded about a year ago).
I compared the INSTALL_Windows.txt and README.txt files in those packages with a diffing tool and there seem to be no differences in required DLLs or other configurations. And both DLLs seem to be compiled with the same version of VS.
Vesa,
Could you try to build the HDF5 JNI dll from the source using native/hdf5lib/nt_makefile?
The two libraries are excluded from the makfile: /NODEFAULTLIB:"MSVCRT" /NODEFAULTLIB:"LIBC.LIB".
Thanks
--pc
Vesa Paatero wrote:
···
Hi,
Thanks. However, it turned out that this problem wasn't essentially a Java issue but could be replicated by C/C++ code that tries to load hdf5dll.dll:
The version 1.8.4p1 of hdf5dll.dll depends on MSVCR80.DLL (which can be downloaded in a VS 2005 redistributables package) but there was some other problem that prevented loading hdf5dll.dll. The dependency walker depends.exe reported that the Side-by-Side configuration information of hdf5dll.dll contains errors. I've reported this to the Helpdesk.
Best Regards,
Vesa Paatero
BiolinScientific
-----Original Message-----
From: Allen D Byrne [mailto:byrn@hdfgroup.org]
Sent: 8. maaliskuuta 2010 19:16
To: hdf-forum@hdfgroup.org
Cc: Vesa Paatero
Subject: Re: [Hdf-forum] Problem loading hdf5dll.dll in v1.8.4 (patch 1) while v1.8.2 works.
Vesa,
The first thing that might be the problem is the call to H5.H5check_version() is failing.
A couple of questions, are you using the pre-built hdf-java or did you build from source.
Also, what version of hdf-java are you using?
Allen
Hi,
When I try a Java test program that first loads zlib1.dll, then szlibdll.dll and finally hdf5dll.dll, it doesn't work in version 1.8.4 (patch 1) even though it works with a hdf5dll.dll of version 1.8.2.
With 1.8.4 (patch 1) the resulting exception conveyed a message like this:
(path+)"hdf5dll.dll: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem"
The platform is Windows XP (32-bit). The library (hdf5dll.dll v1.8.4) originates from downloaded package hdf5-1.8.4-patch1-32bit-vs2005-ivf91.zip . The hdf5dll.dll of version 1.8.2 originates from package 5-182-win-vs2005.zip (downloaded about a year ago).
I compared the INSTALL_Windows.txt and README.txt files in those packages with a diffing tool and there seem to be no differences in required DLLs or other configurations. And both DLLs seem to be compiled with the same version of VS.
