Open FlorianLudwig opened 1 month ago
have you tried installing cross from the current main branch?
cargo install cross --git https://github.com/cross-rs/cross
With version cross 0.2.5 (ac4c11c 2024-09-24)
I get:
error: failed to run custom build command for `aws-lc-sys v0.20.1`
Caused by:
process didn't exit successfully: `/target/release/build/aws-lc-sys-18f2c886ba4b2157/build-script-main` (exit status: 101)
--- stdout
cargo:rerun-if-env-changed=AWS_LC_SYS_NO_PREFIX
cargo:rerun-if-env-changed=AWS_LC_SYS_INTERNAL_BINDGEN
cargo:rerun-if-env-changed=AWS_LC_SYS_EXTERNAL_BINDGEN
cargo:rerun-if-env-changed=AWS_LC_SYS_NO_ASM
cargo:rustc-cfg=x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=AWS_LC_SYS_CMAKE_BUILDER
cargo:rerun-if-env-changed=AWS_LC_SYS_STATIC
default_for Target: 'x86_64-unknown-linux-gnu'
cargo:rerun-if-env-changed=CARGO_FEATURE_SSL
default_for Target: 'x86_64-unknown-linux-gnu'
cargo:rerun-if-env-changed=CARGO_FEATURE_SSL
cargo:root=/target/x86_64-unknown-linux-gnu/release/build/aws-lc-sys-26d78042895e775b/out
default_for Target: 'x86_64-unknown-linux-gnu'
OPT_LEVEL = Some(3)
TARGET = Some(x86_64-unknown-linux-gnu)
OUT_DIR = Some(/target/x86_64-unknown-linux-gnu/release/build/aws-lc-sys-26d78042895e775b/out)
HOST = Some(x86_64-unknown-linux-gnu)
cargo:rerun-if-env-changed=CC_x86_64-unknown-linux-gnu
CC_x86_64-unknown-linux-gnu = None
cargo:rerun-if-env-changed=CC_x86_64_unknown_linux_gnu
CC_x86_64_unknown_linux_gnu = None
cargo:rerun-if-env-changed=HOST_CC
HOST_CC = None
cargo:rerun-if-env-changed=CC
CC = None
cargo:rerun-if-env-changed=CC_ENABLE_DEBUG_OUTPUT
RUSTC_WRAPPER = None
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)
cargo:rerun-if-env-changed=CFLAGS_x86_64-unknown-linux-gnu
CFLAGS_x86_64-unknown-linux-gnu = None
cargo:rerun-if-env-changed=CFLAGS_x86_64_unknown_linux_gnu
CFLAGS_x86_64_unknown_linux_gnu = None
cargo:rerun-if-env-changed=HOST_CFLAGS
HOST_CFLAGS = None
cargo:rerun-if-env-changed=CFLAGS
CFLAGS = None
--- stderr
thread 'main' panicked at /home/fludwig/.cargo/registry/src/index.crates.io-6f17d22bba15001f/aws-lc-sys-0.20.1/builder/cc_builder.rs:244:13:
Your compiler (cc) is not supported due to a memcmp related bug reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189.We strongly recommend against using this compiler.EXECUTED: true ERROR: OUTPUT:
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Which is an unrelated issue. I will have dig another day what is wrong there.
that's a known issue, you use aws-lc-sys from their master branch to resolve it for now. https://github.com/aws/aws-lc-rs/pull/520
edit: actually, for x86_64-unknown-linux-gnu that might not work
@Emilgardis Hi, I am running into a similar issue to the above.
I am trying to compile a project that depends on aws-lc-sys v0.22.0
like so:
cargo tree | grep aws-lc-sys
│ │ ├── aws-lc-sys v0.22.0
cross build --release --target x86_64-unknown-linux-gnu
The output includes:
--- stderr
thread 'main' panicked at /home/shared/.cargo/registry/src/index.crates.io-6f17d22bba15001f/aws-lc-sys-0.22.0/builder/cc_builder.rs:333:13:
### COMPILER BUG DETECTED ###
Your compiler (cc) is not supported due to a memcmp related bug reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189. We strongly recommend against using this compiler.
EXECUTED: true
ERROR:
OUTPUT:
Have you found a workaround for x86_64-unknown-linux-gnu
by chance? Thanks in advance
EDIT: This comment seems to suggest that one option would be to update gcc
: https://github.com/rustls/rustls/issues/1967#issuecomment-2279067420
Checklist
Describe your issue
When using cross on a system with SE Linux enabled,
What target(s) are you cross-compiling for?
No response
Which operating system is the host (e.g computer cross is on) running?
What architecture is the host?
What container engine is cross using?
cross version
cross 0.2.5
Example
Running on fedora 40 with podman and SELinux enabled in a project that contains a local dependency:
Additional information / notes
Instead of using
:z
which relabels the files in a mount, using--security-opt label=disable
is a much more reliable option in my experience. It also fixes the issue for me in this case.