Support cross-compiling when using Bazel platforms

[PiotrSikora]

Bazel has a decent support for building for a different target platforms (CPU/OS), but it's missing official toolchains to make it really easy for the end users to cross-compile.

Luckily for us, one such toolchain recently appeared: bazel-zig-cc (using zig cc/zig c++ drop-in replacement for GCC/Clang).

When cross-compiling for a different target (e.g. using --platforms @zig_sdk//:linux_aarch64_platform), which sets appropriate @platforms constraints, most of the Bazel rules "just work", however rules using cmake() are building for the host platform, since none of the standard cross-compiling CMake variables are set by rules_foreign_cc:

$ bazel build --incompatible_enable_cc_toolchain_resolution --platforms @zig_sdk//:linux_aarch64_platform --extra_toolchains @zig_sdk//:aarch64-linux-gnu.2.33_toolchain ...
[...]
-- DEBUG: CMAKE_CROSSCOMPILING='FALSE'
-- DEBUG: CMAKE_C_COMPILER_TARGET=''
-- DEBUG: CMAKE_SYSTEM_PROCESSOR='x86_64'

[jheaff1]

It’s strange that cross compiling doesn’t work for you; I can cross compile the zlib example for Android using the cmake rule just fine.

[PiotrSikora]

@jheaff1 that's not a good example, because zlib's build doesn't depend on the target platform detection (i.e. the same C source files are compiled on all the platforms, see: madler/zlib's CMakeLists.txt).

Try anything that depends on ${CMAKE_SYSTEM_PROCESSOR} for selecting platform-specific files, and you'll see build failures, because cmake() will select files for the host and not the target platform.

[jheaff1]

Ah I see.

Perhaps once this issue is resolved, the CI of this repo should utilise the zig toolchain to cross compile libjpeg_turbo, which relies on ${CMAKE_SYSTEM_PROCESSOR}

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_foreign_cc!

[cpsauer]

Bump, since still open and useful.

Related: #289

[CareF]

There seems to have an issue when tool_paths is using relative paths (which would be the case if the cc tools are managed by bazel as a third party dependency)

This seems to be related with https://github.com/bazelbuild/bazel/issues/8438#issuecomment-594443436

[jheaff1]

@CareF To workaround the issue you could wrap the toolchain executables in a script that prepends the path with EXT_BUILD_ROOT, which is set by rules_foreign_cc. An example of this is here:

https://github.com/aspect-build/gcc-toolchain/blob/main/toolchain/wrapper.sh.tpl