RUSTFLAGS sometimes isn't passed to all rustc command lines

[yurivict]

In some projects the RUSTFLAGS are ignored and not passed to rustc, at least on the i386 architecture.

Testcase: https://github.com/drahnr/cargo-spellcheck
cargo is called with the RUSTFLAGS environment variable containing "-C target-feature=+sse,+sse2".
Yet this RUSTFLAGS value is not passed to rustc.

Build log on i386.
It shows the build failure because the above RUSTFLAGS wasn't passed to the rustc command line.

Meta

$ rustc --version --verbose
rustc 1.79.0 (129f3b996 2024-06-10) (built from a source tarball)
binary: rustc
commit-hash: 129f3b9964af4d4a709d1383930ade12dfe7c081
commit-date: 2024-06-10
host: x86_64-unknown-freebsd
release: 1.79.0
LLVM version: 18.1.7

OS: FreeBSD 14.1
The builds are done in the FreeBSD ports framework.

[saethlin]

cargo is called with the RUSTFLAGS environment variable containing "-C target-feature=+sse,+sse2".

I cannot find mention of target-feature anywhere in the build log or that repo. Where is RUSTFLAGS being set?

[yurivict]

The RUSTFLAGS environment variable is set to "-C target-feature=+sse,+sse2" when cargo is called.
This isn't shown in the log.

[workingjubilee]

This build log is for an entirely different repo.

[workingjubilee]

@yurivict Would you link me to your complete build setup for these? Your log suggests you are applying patches, using a .cargo/config.toml, and more, and there is a strong possibility you are setting something that cargo interprets as deliberately overriding the RUSTFLAGS env var. A log for a different repo and without the build-relevant env vars being used is inadequate.

[yurivict]

@workingjubilee

Sorry for the log confusion.

Here is the full build log including the full cargo invocation.

It shows that "-C target-feature=+sse,+sse2" argument is passed to some rustc commands but not to all of them, and the build failure is caused by the lack of these target features.

[ehuss]

When using the --target flag, cargo will not pass RUSTFLAGS to things built for the host (such as build scripts and proc-macros). Unfortunately the option to fix that is still unstable, but you can read more about the host config option.

It's not clear from the build logs exactly why ring does not build for x86_64-unknown-freebsd (assuming that is your host) without the given options. That seems like a limitation of ring that you might want to investigate.

[yurivict]

It's not clear from the build logs exactly why ring does not build for x86_64-unknown-freebsd (assuming that is your host) without the given options.

Both host and target architectures are i386 in this case.
The build is performed in the i386 VM (FreeBSD jail) on the amd64 VM host, but amd64 isn't visible to the build.

The build fails because sse2 is disabled on i386 by default, and needs to be enabled.

[yurivict]

Unfortunately the option to fix that is still unstable, but you can read more about the host config option.

What would be the working (though potentially unstable) option to pass to CARGO to fix this?
We have many rust-based ports failing on i386 for the same reason.

[yurivict]

@ehuss

The host config option appears to be for a cross-compilation situation, while we run the i386 build in the i386 VM, so that there is no cross-compilation.

[ehuss]

"Cross compilation" in this instance is equivalent to passing --target, even if the target is the same as the host.
If you don't want to put cargo into this "cross compilation" mode, don't pass --target.

[yurivict]

@ehuss

Thank you. It looks like we need to disable cross-compilation in the FreeBSD ports framework.

I suggested this here.

Thank you for your help.

[workingjubilee]

@yurivict I am perplexed. Why does SSE2 have to be enabled for the host?