Cross compiling HDF5 for aarch64

HDF5 Library
21

You’re right.
The only solution that worked was using Docker and toolchain that comes with it.

I’ll also test with u22.04 + musl later for you. I’m sure it will fail though.

22

@chch206265, thank you for being very specific about platform requirement.

u22.04 + musl worked fine.

See https://github.com/hyoklee/hdf5/actions/runs/3516693293 for the result.

23

I am all gratitude.But when I run “make” ,it happenes：
/bin/sh: 1: /home/lixiang/Downloads/hdf5_new/hdf5/arm_build/bin/H5make_libsettings: Exec format error

The Build platform is linux, and the generated H5make_libsettings is in ARM aarch64 format, which cannot be run on the build platform. Please let me know how you did it？
I just cannot thank you enough.

24

Everything seems to be back to square one…

25

Would you please copy and paste your cmake [build options] .. line?

26

Of course.
Using like this:
cmake -DCMAKE_C_COMPILER=/home/cc/Downloads/musl-cross-make/output/bin/aarch64-linux-musl-gcc -DCMAKE_AR=/home/cc/Downloads/musl-cross-make/output/bin/aarch64-linux-musl-ar -DBUILD_SHARED_LIBS=OFF -DCMAKE_SYSTEM_PROCESSOR=arm …

27

So you couldn’t cross compile on x86_64 for aarch64?
What is currently the solution for this? Only using docker?

28

Yes, I could.
CMake + qemu + musl worked fine.
It took ony 35 minutes.
Docker took 3 hours.

29

I think it’s due to CMake caching.
Can you clean up CMake build directory (i.e., rm -rf build)?

Also, what’s your CMake version?

30

CMake cross-compiling needs certain CMake vars set. We use the files in config/cmake/toolchain for setting the vars; see the mingw64.cmake and compare it to the clang.cmake or GCC.cmake file.

Here is a possible setting:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)

set(CMAKE_COMPILER_VENDOR “clang”)

if(WIN32)
set(CMAKE_C_COMPILER clang-cl)
set(CMAKE_CXX_COMPILER clang-cl)
else()
set(CMAKE_C_COMPILER clang)
set(CMAKE_CXX_COMPILER clang++)
endif()
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

the following is used if cross-compiling

set(CMAKE_CROSSCOMPILING_EMULATOR “”)

Here is the text for a possible INSTALL_cross_compiling.txt file:

  •   HDF5 Build and Install Instructions for Cross Compiling       *

Cross-compiling has several consequences for CMake:
CMake cannot automatically detect the target platform.
CMake cannot find libraries and headers in the default system directories.
Executables built during cross compiling cannot be executed.

Cross-compiling support means that CMake separates information about the
build platform and target platform and gives the user mechanisms to solve
cross-compiling issues without additional requirements such as running
virtual machines, etc.

CMake uses a toolchain of utilities to compile, link libraries and create
archives, and other tasks to drive the build. The toolchain utilities
available are determined by the languages enabled.

CMake stores info about the current toolchain in the following variables:
CMAKE_C_COMPILER,
CMAKE_CXX_COMPILER.
They contain paths to the C and C++ compilers respectively. This is usually
enough on desktop platforms. In the case of the embedded systems, also a
custom linker and assembler setting is needed. In more complex projects
you may need to additionally specify binaries to other parts of the toolchain
(size, ranlib, objcopy…). All these tools should be set in the corresponding
variables:
CMAKE_AR,
CMAKE_ASM_COMPILER,
CMAKE_LINKER,
CMAKE_OBJCOPY,
CMAKE_RANLIB

As for the host and target operating systems, CMake stores their names in the
following variables:
CMAKE_HOST_SYSTEM_NAME
– name of the platform, on which CMake is running (host platform).
On major operating systems this is set to the Linux, Windows or
Darwin (MacOS) value.
CMAKE_SYSTEM_NAME
– name of the platform, for which we are building (target platform).
By default, this value is the same as CMAKE_HOST_SYSTEM_NAME, which
means that we are building for the local platform (no cross-compilation).

Put the toolchain variables into a separate file (e.g. <toolchain_name>.cmake)
and set CMAKE_TOOLCHAIN_FILE variable to the path of that file.
If cmake is invoked with the command line parameter:
–toolchain path/to/file
or
-DCMAKE_TOOLCHAIN_FILE=path/to/file
the file will be loaded early to set values for the compilers. The
CMAKE_CROSSCOMPILING variable is set to true when CMake is cross-compiling.

Structure of the toolchain file

In fact, the toolchain file doesn’t have any structure. You can put anything you
want there. But the best practice is to define at least these settings:
path to the toolchain binaries (C compiler, C++ compiler, linker, etc.)
name of the target platform (and optionally target processor architecture)
required compilation and linking flags on that particular platform
toolchain sysroot settings

References:
https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html
https://gitlab.com/embeddedlinux/libs/platform

34

I found out why!

  1. Not running: sudo apt-get install apt-get install qemu-user-static binfmt-support
  2. Did not put the lib folder in the musl toolchain into /lib/
    It works!
    Thanks!U save my dayyyyyyyyyyy.
    It’s amazing!
1 Like
35

This looks like another workaround, but which values need to be changed may require more detailed reference documentation

36

Thanks!I will try it if I have free time!

37

At the same time,I’m curious what’s the specific difference between this branch and the trunk?

38

Hi,

Thank you very much for trying so hard and
confirming that my workflow example worked for you.
I’m so happy when our user feels amazing. :heart:

Please keep us updated on your HDF aarch64 application development.
I hope I can see your cool HDF application from
Google Play Store / Apple App Store / Meta Quest Store soon! :heart_eyes:

1 Like
39

Do you mean the difference between

trunk: https://githhub.com/HDFGroup/hdf5

and

branch (=fork): https://github.com/hyoklee/hdf5 ?

If so, the branch is for testing various cutting edge features that I want to test
because I’m neither main developer nor maintainer of the trunk.
My main duty is to support NASA HDF Earthdata users.

1 Like