How can I set target-feature in a manner that doesn't affect build.rs?

1

So, I just observed some behavior that does not match my mental model of build.rs, and would like to fix said mental model.

If I clone rustix and build it with avx512 support (requires nightly)...

git clone https://github.com/bytecodealliance/rustix.git
cd rustix
RUSTFLAGS='-C target-feature=+avx512f' cargo +nightly build

...on my machine, which does not have AVX-512 support, the build crashes with a SIGILL:

warning: unstable feature specified for `-Ctarget-feature`: `avx512f`
  |
  = note: this feature is not stably supported; its behavior can change in the future

warning: `rustix` (build script) generated 1 warning
   Compiling rustix v0.38.31 (/home/hadrien/Archives/CodeMaintenu/rustix)
error: failed to run custom build command for `rustix v0.38.31 (/home/hadrien/Archives/CodeMaintenu/rustix)`
note: To improve backtraces for build dependencies, set the CARGO_PROFILE_DEV_BUILD_OVERRIDE_DEBUG=true environment variable to enable debug information generation.

Caused by:
  process didn't exit successfully: `/home/hadrien/Archives/CodeMaintenu/rustix/target/debug/build/rustix-da84015a745daa37/build-script-build` (signal: 4, SIGILL: illegal instruction)
  --- stdout
  cargo:rerun-if-changed=build.rs

A quick round trip through the debugger confirms my initial intuition that the problem is that the build script is built for an AVX-512 host and thus contains AVX-512 instructions that are indeed illegal on my machine.

Dump of assembler code for function _ZN3std2fs8metadata17h1182e160ea4c07b2E:
       [ ... ]
   0x000055555556b3fc <+124>:   cmp    $0x0,%rax
   0x000055555556b400 <+128>:   jne    0x55555556b49e <_ZN3std2fs8metadata17h1182e160ea4c07b2E+286>
=> 0x000055555556b406 <+134>:   vmovdqu64 0x30(%rsp),%zmm0
   0x000055555556b411 <+145>:   vmovdqu64 0x70(%rsp),%zmm1
   0x000055555556b41c <+156>:   vmovdqu64 0xa0(%rsp),%zmm2
   0x000055555556b427 <+167>:   vmovdqu64 %zmm2,0x150(%rsp)
   0x000055555556b432 <+178>:   vmovdqu64 %zmm1,0x120(%rsp)
   0x000055555556b43d <+189>:   vmovdqu64 %zmm0,0xe0(%rsp)
   0x000055555556b448 <+200>:   vmovdqu64 0xe0(%rsp),%zmm0
   0x000055555556b453 <+211>:   vmovdqu64 0x120(%rsp),%zmm1
   0x000055555556b45e <+222>:   vmovdqu64 0x150(%rsp),%zmm2
   0x000055555556b469 <+233>:   vmovdqu64 %zmm2,0x2b0(%rsp)
   0x000055555556b474 <+244>:   vmovdqu64 %zmm1,0x280(%rsp)
   0x000055555556b47c <+252>:   vmovdqu64 %zmm0,0x240(%rsp)
   0x000055555556b484 <+260>:   lea    0x190(%rsp),%rdi
   0x000055555556b48c <+268>:   lea    0x240(%rsp),%rsi
   0x000055555556b494 <+276>:   vzeroupper
       [ ... ]

...what I don't understand is why. My understanding from reading other threads was that target configuration should affect the output binary, but not the build script.

Obviously this understanding seems flawed, and I suspect that RUSTFLAGS is too big a sledgehammer and affects the build script build too. If so, my question becomes, how can I set target-feature flags for the output binary without affecting the build script?

2

Solution you don't want is to cross compile on aa64/rv64/other-target machine to avoid the error.

3

Thanks for the explanation of what's going on. It gave me an idea for a better workaround: just use --target x86_64-unknown-linux-gnu (i.e. host triplet).