RUSTFLAGS sometimes isn't passed to all rustc command lines about rust HOT 19 CLOSED

@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.

from rust.

But the actual --target passed is --target i686-unknown-freebsd, and the host and the target are "the same", and I don't see a patch in FreeBSD to add an i386 target. So all that you said doesn't matter.

Ah, I see, FreeBSD patches their i686 target to be the Pentium Pro and has not upstreamed this patch, it seems.

https://github.com/freebsd/freebsd-ports/blob/94c86dc918dc3051f23d3b05a33ff4b45b05ec78/lang/rust/files/patch-compiler_rustc__target_src_spec_targets_i686__unknown__freebsd.rs

@yurivict Has FreeBSD considered:

• upstreaming a patch to rustc for their target?
• upstreaming a patch to ring to support non-SSE2 CPUs?
  • see https://github.com/briansmith/ring/blob/7c0024abaf4fd59250c9b79cc41a029aa0ef3497/src/cpu/intel.rs#L18
• caching the results of build scripts that use ring to build a TLS implementation so they can access the internet securely at build time?
• not patching a target downstream and then filing issues when their downstream patch for that target breaks actually trying to build stuff?

from rust.

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?

from rust.

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

from rust.

This build log is for an entirely different repo.

from rust.

@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.

from rust.

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.

from rust.

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.

from rust.

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.

from rust.

@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.

from rust.

"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.

from rust.

@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.

from rust.

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

from rust.

i686-unknown-freebsd uses the pentium4 so this assertion should pass.

from rust.

@workingjubilee

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

I believe that this is an LLVM setup that sse2 isn't enabled by default on i386.

from rust.

upstreaming a patch to ring to support non-SSE2 CPUs?

According to the FreeBSD policy, the lowest supported CPU supports SSE2.

[...] so they can access the internet securely at build time?

Accessing the internet at build time isn't allowed during port build for security reasons.

from rust.

That is an understandable limitation, but if so, I'm not sure how a build is failing for the above-described reasons? The only reason I can think of to build ring during a build script is the thing I mentioned.

Anyway, your build should work if the patch I linked is removed from the FreeBSD ports repo. Or... a patch is added which unpatches the patch, I suppose? I don't know how you all prefer your software over there, exactly.

from rust.

Anyway, your build should work if [the patch I linked] is removed from the FreeBSD ports repo.

It also succeeds when the --target options are removed. Default target should be used, no cross-compilation is allowed to happen by default.

from rust.

That is also fine!

I'm just not sure why, if FreeBSD mandates an SSE2 minimum, that y'all would then patch your 32-bit x86 target to not have SSE2.

from rust.