Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
shpala opened this issue Jan 27, 2024 · 0 comments

Comments

@shpala
Copy link
Contributor

shpala commented Jan 27, 2024

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 ..

shpala pushed a commit to shpala/speedb that referenced this issue Jan 27, 2024
by manually setting CMAKE_SYSTEM_PROCESSOR to the cross-compilation target
whenever CMAKE_SYSTEM_PROCESSOR doesn't match CMAKE_OSX_ARCHITECTURES after project() call.
This is probably a Cmake bug that happens on macOS.
(speedb-io#822)
@shpala shpala changed the title Cross-compilation issue with projects that use SpeeDB built using Cmake on macOS with x86_64 CPU and targeted for arm64 CPUs Workaround for a Cmake bug that happens when cross-compiling using Cmake on macOS x86_64 CPUs with target CPU arm64 Jan 27, 2024
shpala pushed a commit to shpala/speedb that referenced this issue Feb 23, 2024
by manually setting CMAKE_SYSTEM_PROCESSOR to the cross-compilation target
whenever CMAKE_SYSTEM_PROCESSOR doesn't match CMAKE_OSX_ARCHITECTURES after project() call.
This is probably a Cmake bug that happens on macOS.
(speedb-io#822)
shpala added a commit to shpala/speedb that referenced this issue Feb 23, 2024
by manually setting CMAKE_SYSTEM_PROCESSOR to the cross-compilation target
whenever CMAKE_SYSTEM_PROCESSOR doesn't match CMAKE_OSX_ARCHITECTURES after project() call.
This is probably a Cmake bug that happens on macOS.
(speedb-io#822)
shpala added a commit to shpala/speedb that referenced this issue Feb 23, 2024
by manually setting CMAKE_SYSTEM_PROCESSOR to the cross-compilation target
whenever CMAKE_SYSTEM_PROCESSOR doesn't match CMAKE_OSX_ARCHITECTURES after project() call.
This is probably a Cmake bug that happens on macOS.
(speedb-io#822)
shpala added a commit to shpala/speedb that referenced this issue Feb 28, 2024
by manually setting CMAKE_SYSTEM_PROCESSOR to the cross-compilation target
whenever CMAKE_SYSTEM_PROCESSOR doesn't match CMAKE_OSX_ARCHITECTURES after project() call.
This is probably a Cmake bug that happens on macOS.
(speedb-io#822)
ofriedma pushed a commit that referenced this issue Feb 29, 2024
by manually setting CMAKE_SYSTEM_PROCESSOR to the cross-compilation target
whenever CMAKE_SYSTEM_PROCESSOR doesn't match CMAKE_OSX_ARCHITECTURES after project() call.
This is probably a Cmake bug that happens on macOS.
(#822)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant