Open demurgos opened 1 year ago
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:
Another solution would be to go through the entrypoint, even with CROSS_REMOTE=1
.
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
```txt 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 usingCROSS_REMOTE=1
, the 4 environment variables defined in the entrypointdarwin-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 theDockerfile
withENV
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.