Avoid critical config in the entrypoint (ignored by CROSS_REMOTE=1)

[demurgos]

During this week, I configured my repo to use GitLab CI to cross-compile to Mac (target x86_64-apple-darwin). I figured it out in the end, but it was a bit tricky.

First of all, I followed the help in this issue which was very helpful. This let me cross compile to ARM. In particular, I've set CROSS_REMOTE=1.

The issue I've hit was that I had ring as a dependency, and it failed to compile in GitLab CI. This was because it used the Linux compiler instead of the the one from osxcross (cc: error: unrecognized command line option '-arch').

Full ring error

error: failed to run custom build command for `ring v0.16.20`
Caused by:
  process didn't exit successfully: `/cross/project/target/release/build/ring-719859dcd2b78047/build-script-build` (exit status: 101)
  --- stdout
  OPT_LEVEL = Some("z")
  TARGET = Some("x86_64-apple-darwin")
  HOST = Some("x86_64-unknown-linux-gnu")
  cargo:rerun-if-env-changed=CC_x86_64-apple-darwin
  CC_x86_64-apple-darwin = None
  cargo:rerun-if-env-changed=CC_x86_64_apple_darwin
  CC_x86_64_apple_darwin = None
  cargo:rerun-if-env-changed=TARGET_CC
  TARGET_CC = None
  cargo:rerun-if-env-changed=CC
  CC = None
  RUSTC_LINKER = None
  cargo:rerun-if-env-changed=CROSS_COMPILE
  CROSS_COMPILE = None
  cargo:rerun-if-env-changed=CFLAGS_x86_64-apple-darwin
  CFLAGS_x86_64-apple-darwin = None
  cargo:rerun-if-env-changed=CFLAGS_x86_64_apple_darwin
  CFLAGS_x86_64_apple_darwin = Some("-stdlib=libc++")
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("false")
  CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2,sse3,ssse3")
  --- stderr
  running "cc" "-Os" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-arch" "x86_64" "-stdlib=libc++" "-I" "include" "-pedantic" "-pedantic-errors" "-Wall" "-Wextra" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wenum-compare" "-Wfloat-equal" "-Wformat=2" "-Winline" "-Winvalid-pch" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wundef" "-Wuninitialized" "-Wwrite-strings" "-fno-strict-aliasing" "-fvisibility=hidden" "-fstack-protector" "-gfull" "-DNDEBUG" "-c" "-o/cross/project/target/x86_64-apple-darwin/release/build/ring-dc3763bb75c01cb2/out/aesni-x86_64-macosx.o" "/cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/pregenerated/aesni-x86_64-macosx.S"
  cc: error: x86_64: No such file or directory
  cc: error: unrecognized debug output level 'full'
  cc: error: unrecognized command line option '-arch'
  cc: error: unrecognized command line option '-stdlib=libc++'
  thread 'main' panicked at 'execution failed', /cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/build.rs:656:9
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "non-success exit status"', xtask/src/main.rs:60:19
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

After adding some debug statements and comparing it to the logs when building locally using cross, I found that when using CROSS_REMOTE=1, the 4 environment variables defined in the entrypoint darwin-entry.sh were missing. In my case, those were:

• AR_x86_64_apple_darwin
• CC_x86_64_apple_darwin
• CXX_x86_64_apple_darwin
• CARGO_TARGET_X86_64_APPLE_DARWIN_LINKER

I did not dig too much into it, but I assume it's because the entrypoint is ignored when using CROSS_REMOTE=1. As a workaround, I created a derived image where I've set the variables directly in the Dockerfile with ENV statements: this fixed the issue.

A solution to avoid this issue would be to avoid putting critical configuration value in the entrypoints. Another solution would be for CROSS_REMOTE to use the entrypoint.

[demurgos]

I looked into writing a fix for this issue. My workaround hardcoded the values, but the proper fix would be to set the ENV fields with the values from the script.
The problem is that both the variable names and values are computed at build time. It seems that a proper fix would depend on first having support for computed env vars in docker:

• Set to ENV the result of command moby/moby#29110

Another solution would be to go through the entrypoint, even with CROSS_REMOTE=1.