zstd-sys: Don't use target* cfg in build.rs to fix Windows cross-compile
#176
Conversation
…compile This issue got exposed with [CC upgrading to 1.0.77] and now detecting the `.S` file extension to pass on to `ml64.exe` (MASM) on Windows; we don't have that on our cross-compiling (from Linux to Windows) CI setup, hence uncovered that this build script was using the _`target_os` flag from the host_ in the build script to make a decision on _what to compile for the target_. [CC upgrading to 1.0.77]: rust-lang/cc-rs@1.0.76...1.0.77
|
Indeed, thanks for identifying and fixing this issue! |
|
Indeed as found in rust-lang/cc-rs#754 the compiler was previously ignoring |
|
Is it possible to make a bugfix release with this fix? This library lies upstream of a cross-compiled project I'd like to make a release for. |
|
Just published zstd-sys 2.0.2. |
MarijnS95
deleted the
buildrs-env-instead-of-target-cfg-for-cross-compile
branch
|
As per rust-lang/cc-rs#754 (comment) I am in hindsight not entirely sure if this is the right solution: since it was compiling just fine before in a cross-compilation setup, were we perhaps having an advantage because If that's true, perhaps we should instead check/force the compiler to be used when cross-compiling, instead of disabling it outright because of expecting If anything |
This issue got exposed with CC upgrading to 1.0.77 and now detecting the
.Sfile extension to pass on toml64.exe(MASM) on Windows; we don't have that on our cross-compiling (from Linux to Windows) CI setup, hence uncovered that this build script was using thetarget_osflag from the host in the build script to make a decision on what to compile for the target.Curiously this implies the
.Sfile must have compiled fine for us oncc 1.0.76and prior, or somehow got skipped (expecting errors whenZSTD_DISABLE_ASMisn't defined...).