Skip to content

Workaround for a Cmake bug that happens when cross-compiling using Cmake on macOS x86_64 CPUs with target CPU arm64 #822

Open
@shpala

Description

@shpala

This is a temporary workaround for Cmake bug that only sets the correct CMAKE_SYSTEM_PROCESSOR for cross-compilation when target CMAKE_SYSTEM_NAME differs from CMAKE_HOST_NAME:
https://gitlab.kitware.com/cmake/cmake/-/issues/25640

Cross-compilation of a project that is linked to SpeeDB on an x86_64 CPU with target CPU as arm64 fails after SpeeDB was built using the following command:
cmake -G "Unix Makefiles" -DCMAKE_SYSTEM_PROCESSOR=arm64 ..
The SpeeDB build itself succeeds, but executable linking with it will return a linking error.
This specific issue only happens when cross-compiling on an macOS machine due to a possible Cmake bug that causes CMAKE_SYSTEM_PROCESSOR to be equal to CMAKE_HOST_SYSTEM_PROCESSOR regardless of the value of CMAKE_OSX_ARCHITECTURES, which in turn causes an issue in SpeeDBs own CMakeLists.txt.
In my case the issue happened when I was building SpeeDB on x86_64 with a CMAKE_OSX_ARCHITECTURES set to "arm64".
Even after manually setting CMAKE_SYSTEM_PROCESSOR with "-DCMAKE_SYSTEM_PROCESSOR=arm64" or even when setting it manually at the top of CMakeLists.txt using set(CMAKE_SYSTEM_PROCESSOR arm64), immediately after the project() call, the CMAKE_SYSTEM_PROCESSOR was reset back to x86_64.
The linking error happens, because due to wrong CMAKE_SYSTEM_PROCESSOR, the variable HAS_ARMV8_CRC gets the wrong value.
This in turn causes Cmake to skip the source append command of "util/crc32c_arm64.cc".

Expected behavior
Successfully compiled executable.

Actual behavior
The following linking error:
Undefined symbols for architecture arm64:
"crc32c_arm64(unsigned int, unsigned char const*, unsigned long)", referenced from:
speedb::crc32c::ExtendARMImpl(unsigned int, char const*, unsigned long) in libspeedb.a(crc32c.cc.o)
"crc32c_runtime_check()", referenced from:
speedb::crc32c::IsFastCrc32Supported() in libspeedb.a(crc32c.cc.o)
__GLOBAL__sub_I_crc32c.cc in libspeedb.a(crc32c.cc.o)
"crc32c_pmull_runtime_check()", referenced from:
speedb::crc32c::IsFastCrc32Supported() in libspeedb.a(crc32c.cc.o)
__GLOBAL__sub_I_crc32c.cc in libspeedb.a(crc32c.cc.o)

nm -C libspeedb.a returns the following:
crc32c.cc.o:
0000000000000dfc s GCC_except_table1
0000000000000e20 s GCC_except_table21
0000000000000e4c s __GLOBAL__sub_I_crc32c.cc
U __Unwind_Resume
U crc32c_arm64(unsigned int, unsigned char const*, unsigned long)
U crc32c_runtime_check()
U crc32c_pmull_runtime_check()
0000000000000860 T speedb::DecodeFixed32(char const*)"

Steps to reproduce the behavior
Cross-compile a project that is linked to SpeeDB on an x86_64 CPU with target CPU as arm64.
cmake -G "Unix Makefiles" -DCMAKE_SYSTEM_PROCESSOR=arm64 ..

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions