HDF5 support on Android

Question

How would one use the HDF5 software on Android? Can the native C++ libraries be compiled for the Android platform, and then called using the HDF5 Java bindings?

Answer 1

You cannot (easily) compile using the cross-compiler for Android

You'll need to compile on an ARM device and specifically an Android toolchain if you want to get this working. In all honesty, don't use HDF5 in an NDK project, because even if you managed to generate a binary it wouldn't be supported.

I went ahead and attempted compiling it using the NDK-CMake-gradle and it fails trying to figure out the size of various types. I've seen this sort of behaviour before and it usually requires uploading executable to an emulator or device, running it and reading back the result. Not cool.

According to their own FAQ:

No, there are two problems with cross-compiling in HDF5.

First, HDF5 uses AC_TRY_RUN in several places. This macro tries to compile and run a test program, but this does not work for cross-compiling because it builds the program for the host system, and tries to run it on the build system. To resolve this the macros would need to be replaced with a a non-dynamic test (that is, determine the correct setting without executing a test program), or amend each AC_TRY_RUN with an argument telling it what to do when cross-compiling (which would likely mean setting a pessimistic default for cross-compilations).

Many of these AC_TRY_RUN instances are for checks of compiler capabilities. For example, HDF5 checks to see if the Fortran compiler supports the intrinsic function "SIZEOF" by running a test program. Based on the result, a makefile conditional is set to toggle which source file to use when building H5test_kind (in this case, either H5test_kind_SIZEOF.f90 or H5test_kind.f90). There are also many C++ compiler checks. Other AC_TRY_RUN checks include: checking if large files are supported, checking if SZIP compression can encode, checking if gettimeofday uses the timezone struct, and many more for checking conversion capabilities.

The second (dealbreaking?) problem is the generation of H5Tinit.c and, to a lesser extent, H5libsettings.c which are actually generated within 'make', not by configure. The programs that generate them are C programs which are compiled to run on the target platform, but they are then run during 'make' on the build platform, and thus fail (or, in some cases, simply produce incorrect results). HDF5 would need to generate these source files during configure without executing a machine-dependent program on the build system. (In other words for H5Tinit.c, HDF5 would need to do what H5detect does, but in a scripting language that can be run during configure on the build platform. Since h5detect is supposed to detect machine byte order and floating point format on the target platform, there is not currently a solution for this.)

An old how-to on getting around this issue

I have posted the rather long instructions on hacking your way around the problems with getting it to compile as a gist called Android HDF5 Compilation How-to.

I have tested this formula against v1.8.18 and it still works. Here is the script I wrote as a starting point to drive the compilation of armeabi, armeabi-v7a and x86.

In testing though, there seem to be problems with some of the library functions causing crashes, so as I originally stated, you should probably avoid HDF5 if you can't get the compile to work cleanly.

Answer 2

well, it is been long time and no one answered. Currently, I am doing a project that support hdf5 format on Android. It turns out a problem I came across.

Compatibility: the current hdf5 library is written in native code. Only work if you use android toolchain to cross compile. note: JHDF5 is a pretty good hdf5 Java library.But compatible problem remains.