CMake build fails building tests for 1.3.2 when cross-compiling Linux Arm and Windows Arm

[Mr-Clam]

The CMakeLists.txt file for the tests assumes that coverage can be built if the compiler is clang (here). Actually, this isn't always true:

FAILED: test/infcover 
: && clang --target=aarch64-none-linux-gnu --gcc-toolchain=/opt/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu --sysroot=/opt/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/libc -fuse-ld=/opt/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-ld -ffp-contract=off   -g -fno-strict-aliasing -Wstrict-aliasing -pipe -Wformat -coverage test/CMakeFiles/infcover.dir/infcover.c.o -o test/infcover  libz.a && :
/opt/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-ld: cannot find /usr/lib/llvm-14/lib/clang/14.0.0/lib/linux/libclang_rt.profile-aarch64.a: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The folder /usr/lib/llvm-14/lib/clang/14.0.0/lib/linux/ contains libclang_rt.profile-x86_64.a and libclang_rt.profile-i386.a; there is no libclang_rt.profile-aarch64.a.

This is a cross-compile build environment running on Ubuntu 22.04 x86_64 and targeting Linux Arm64.

[Vollstrecker]

Doesn't that file exist at all, or is just another package needed? Detect crosscompiling is possible, the question is, are there additional things to check, or is this kind of test just not possible?

[Mr-Clam]

Yes, it doesn't exist at all.

It's possible I missed something, but I didn't see anything appropriate when I ran apt list | grep -e clang-14 -e llvm-14. When I ran apt list | grep aarch, I mostly got a list of gcc and binutils related packages. Maybe it's because clang natively supports cross-compilation?

I checked clang+llvm-14.0.6-aarch64-linux-gnu.tar.xz, and found it exists in that package. My guess it requires a native Arm64 build of clang to get this file.

Our Windows on Arm build also failed at the same point, although for a different reason. We use clang-cl from LLVM 21 on Linux to cross-compile this:

lld-link: warning: ignoring unknown argument '-coverage'
lld-link: error: undefined symbol: llvm_gcda_start_file
>>> referenced by test/CMakeFiles/infcover.dir/infcover.c.obj:(__llvm_gcov_writeout)

lld-link: error: undefined symbol: llvm_gcda_emit_function
>>> referenced by test/CMakeFiles/infcover.dir/infcover.c.obj:(__llvm_gcov_writeout)

lld-link: error: undefined symbol: llvm_gcda_emit_arcs
>>> referenced by test/CMakeFiles/infcover.dir/infcover.c.obj:(__llvm_gcov_writeout)

lld-link: error: undefined symbol: llvm_gcda_summary_info
>>> referenced by test/CMakeFiles/infcover.dir/infcover.c.obj:(__llvm_gcov_writeout)

lld-link: error: undefined symbol: llvm_gcda_end_file
>>> referenced by test/CMakeFiles/infcover.dir/infcover.c.obj:(__llvm_gcov_writeout)

lld-link: error: undefined symbol: llvm_gcov_init
>>> referenced by test/CMakeFiles/infcover.dir/infcover.c.obj:(__llvm_gcov_init)

FWIW, I can tell you that the shared builds (release and debug) of zlib succeeded and it was the debug static one that failed. I suppose release static would also fail, but we build all of these independently. That's for both Linux Arm and Windows Arm.

I've worked around the issue by setting ZLIB_BUILD_TESTING=OFF. We weren't running the tests anyway, so at best they were only performing an integration test. I have no idea if other people would cross-compile and then run these tests separately on a different machine.

[Vollstrecker]

Interesting, it fails because of an unknown option and undefined symbols this option adds. Could you also test this with gcc, so we can see if deactivating it when crosscompiling or when crosscompiling with clang is the right thing. I know crosscompiling only by name, so I'm not able to figure this in a reasonable time.

[Mr-Clam]

For the Linux Arm build, I hacked our Cmake toolchain to use the Linaro GCC compiler instead of clang, and it built successfully.

For the Windows Arm build, well, there's nothing I can do there. I can't use GCC because this is specifically a clang-cl (not just clang) build, which creates binaries that are compatible with the Microsoft C++ compiler amongst other things.

[theAeon]

Currently trying to cross compile using a very early-stage aarch64-w64-mingw32-gcc build and failing at

[ 87%] Linking C executable ../bin/infcover.exe
aarch64-w64-mingw32-gcc-ar qc CMakeFiles/static_minigzip.dir/objects.a @CMakeFiles/static_minigzip.dir/objects1.rsp
cd /home/andrew/gnu-toolchain-windows-arm64/build/aarch64-w64-mingw32/zlib/test && /usr/bin/cmake -E cmake_link_script CMakeFiles/infcover.dir/link.txt --verbose=1
aarch64-w64-mingw32-gcc-ar qc CMakeFiles/zlib_static_example.dir/objects.a @CMakeFiles/zlib_static_example.dir/objects1.rsp
/home/andrew/install/toolchains/aarch64-linux-gnu/aarch64-w64-mingw32-ucrt/bin/aarch64-w64-mingw32-gcc -flto=auto -fno-fat-lto-objects -Wl,--whole-archive CMakeFiles/static_minigzip.dir/objects.a -Wl,--no-whole-archive -o ../bin/static_minigzip.exe -Wl,--out-implib,../lib/libstatic_minigzip.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/static_minigzip.dir/linkLibs.rsp
aarch64-w64-mingw32-gcc-ar qc CMakeFiles/zlib_static_example64.dir/objects.a @CMakeFiles/zlib_static_example64.dir/objects1.rsp
/home/andrew/install/toolchains/aarch64-linux-gnu/aarch64-w64-mingw32-ucrt/bin/aarch64-w64-mingw32-gcc -flto=auto -fno-fat-lto-objects -Wl,--whole-archive CMakeFiles/zlib_static_example.dir/objects.a -Wl,--no-whole-archive -o ../bin/zlib_static_example.exe -Wl,--out-implib,../lib/libzlib_static_example.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/zlib_static_example.dir/linkLibs.rsp
/usr/bin/cmake -E rm -f CMakeFiles/infcover.dir/objects.a
/home/andrew/install/toolchains/aarch64-linux-gnu/aarch64-w64-mingw32-ucrt/bin/aarch64-w64-mingw32-gcc -flto=auto -fno-fat-lto-objects -Wl,--whole-archive CMakeFiles/zlib_static_example64.dir/objects.a -Wl,--no-whole-archive -o ../bin/zlib_static_example64.exe -Wl,--out-implib,../lib/libzlib_static_example64.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/zlib_static_example64.dir/linkLibs.rsp
aarch64-w64-mingw32-gcc-ar qc CMakeFiles/infcover.dir/objects.a @CMakeFiles/infcover.dir/objects1.rsp
/home/andrew/install/toolchains/aarch64-linux-gnu/aarch64-w64-mingw32-ucrt/bin/aarch64-w64-mingw32-gcc -flto=auto -fno-fat-lto-objects -coverage -Wl,--whole-archive CMakeFiles/infcover.dir/objects.a -Wl,--no-whole-archive -o ../bin/infcover.exe -Wl,--out-implib,../lib/libinfcover.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/infcover.dir/linkLibs.rsp
/home/andrew/install/toolchains/aarch64-linux-gnu/aarch64-w64-mingw32-ucrt/aarch64-w64-mingw32/bin/ld: /tmp/ccf91SdX.ltrans0.ltrans.o:(.text+0xd104): undefined reference to `__gcov_exit'
collect2: error: ld returned 1 exit status

which does appear to be a failure w/ linking coverage as well.

[Vollstrecker]

Seems like there is some combination running the test in an emulator and generating the output on the host machine involved. I deactivated this test for now.

Could someone check if setting CMAKE_CROSSCOMPILING_EMULATOR would do the trick with a not "fixed" version?