Making build tools aware of cross-compilation

[nicholasjng]

Hello cibuildwheel community,

I am facing another Bazel-related build problem using cibuildwheel. This is explicitly not a fault in cibuildwheel, I just wanted to ask for a clever way to cross-compile in a wheel build for macOS M1 using setuptools extensions.

The situation:

1. Bazel builds a correct ARM wheel on my arm64 laptop, so the package builds fine if sys.platform == target_arch.
2. cibuildwheel's cross-compilation also works exactly as intended, producing a macosx_11_0_arm64.whl wheel. However, upon importing the package on ARM, it complains about a shared library built for x86_64:

ImportError: dlopen(/Users/nicholasjunge/Workspaces/c++/benchmark/venv/lib/python3.9/site-packages/google_benchmark/_benchmark.cpython-39-darwin.so, 0x0002): tried: '/Users/nicholasjunge/Workspaces/c++/benchmark/venv/lib/python3.9/site-packages/google_benchmark/_benchmark.cpython-39-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/local/lib/_benchmark.cpython-39-darwin.so' (no such file), '/usr/lib/_benchmark.cpython-39-darwin.so' (no such file)

3. Said wheel contains this exact shared library, which is built as a Bazel target with a bazel build command emitted by a custom setuptools Extension class.

Given these facts, it seems clear to me that while cibuildwheel recognizes the need to cross-compile, bazel does not. I did some research on this and found some promising bazel build switches that allow me to change the target platform.

The question: How do I best pass this switch containing the target CPU arch to bazel build in the setup.py using cibuildwheel's tools and functionality? I thought of

1. Reading it in from sys.argv, which seems like a rather hacky solution,
2. Reading in a value from an environment variable signalling cross-compilation,
3. Writing the target CPU platform before the build to a .bazelrc file, which is consumed by bazel at build time.

In my mind, this will probably involve some form of updating the setup.py, but this is AFAICT not a dealbreaker.

Thank you for your consideration!

[henryiii]

I'd take advantage of this:

cibuildwheel/cibuildwheel/macos.py

Lines 207 to 220 in 5255155

	if python_configuration.version not in {"3.6", "3.7"}:
	if config_is_arm64:
	# macOS 11 is the first OS with arm64 support, so the wheels
	# have that as a minimum.
	env.setdefault("_PYTHON_HOST_PLATFORM", "macosx-11.0-arm64")
	env.setdefault("ARCHFLAGS", "-arch arm64")
	elif config_is_universal2:
	env.setdefault("_PYTHON_HOST_PLATFORM", "macosx-10.9-universal2")
	env.setdefault("ARCHFLAGS", "-arch arm64 -arch x86_64")
	elif python_configuration.identifier.endswith("x86_64"):
	# even on the macos11.0 Python installer, on the x86_64 side it's
	# compatible back to 10.9.
	env.setdefault("_PYTHON_HOST_PLATFORM", "macosx-10.9-x86_64")
	env.setdefault("ARCHFLAGS", "-arch x86_64")

[nicholasjng]

Thank you for the suggestion! I solved it like this, and the resulting wheels are working properly:

# setup.py

archflags = os.getenv("ARCHFLAGS", "")
if sys.platform == "Darwin" and platform.machine() == "x86_64":
    if "arm64" in archflags:
        # bazel_argv contains the "bazel build" command
        bazel_argv.append(["--cpu=darwin_arm64", "--macos_cpus=arm64"])

So in the end, it relies on the fact that ARCHFLAGS is set, which you mentioned might be more portable than CIBUILDWHEEL_* environment variables.

[joerick]

This sounds like another vote in favour of the CIBUILDWHEEL_* env vars we've mooted previously.

[joerick]

Cross-referencing #944

[henryiii]

I'd respond with the same comment as there. If you use standard variables like ARCHFLAGS, you will support conda-forge and all other ways to build wheels, while relying on CIBW variables will tie to you just building inside cibuildwheel and that's it.