Cross-compilation with cargo xwin fails when sccache is enabled with GLIBC>=2.38
#30
Comments
|
That is rather suspicious, the target file Perhaps |
The unfortunately named `target_cfg`, when used in a `cfg()` macro / attribute is a *host* flag (as all other `cfg()`s) when a build script _using this library_ is compiled for the host. Instead, the `ENV` of the compile _target_ should be used to deduce what the environment is. This causes an `xwin` cross-compile (reported in jean-airoldie#30) to invoke the `glibc` compile test even though windows doesn't provide `glibc`. When cross-compiling to `x86_64-pc-windows-msvc` `target_env` will still be `"gnu"` while `CARGO_CFG_TARGET_ENV` properly represents `msvc`. Aside from this I do think that the compile-check is valid for MSVC, the warning in that error even suggests to include `<string.h>`, but the test `.c` file already does exactly this... Perhaps the arguments set up by `xwin` and/or the `sccache` wrapper there are incompatible with how we invoke the compiler for this test?
|
Cooked up a fix so that this test script shouldn't be invoked in the first place: It was guarded by Note that I still have a feeling that this test could/should be executed on MSVC as well and use the native implementation. At least the error message suggests that it's available in |
The unfortunately named `target_cfg` used in a `cfg()` macro / attribute is a *host* flag (as all other `cfg()`s) when a build script _using this library_ is compiled for the host. Instead, the `ENV` of the compile _target_ should be read from an environment variable (just like `$TARGET`) when this code is being run _on the host_ to figure out what the target environment ABI is. This causes a cross-compile via `xwin` (reported in jean-airoldie#30) to invoke the `glibc` compile test even though windows doesn't provide `glibc`. When cross-compiling to `x86_64-pc-windows-msvc` `target_env` will still be `"gnu"` while `CARGO_CFG_TARGET_ENV` properly represents `msvc`. Aside from this I do think that the compile-check is valid for MSVC, the warning in that error even suggests to include `<string.h>`, but the test `.c` file already does exactly this... Perhaps the arguments set up by `xwin` and/or the `sccache` wrapper there are incompatible with how we invoke the compiler for this test?
…nu` (#31) The unfortunately named `target_cfg` used in a `cfg()` macro / attribute is a *host* flag (as all other `cfg()`s) when a build script _using this library_ is compiled for the host. Instead, the `ENV` of the compile _target_ should be read from an environment variable (just like `$TARGET`) when this code is being run _on the host_ to figure out what the target environment ABI is. This causes a cross-compile via `xwin` (reported in #30) to invoke the `glibc` compile test even though windows doesn't provide `glibc`. When cross-compiling to `x86_64-pc-windows-msvc` `target_env` will still be `"gnu"` while `CARGO_CFG_TARGET_ENV` properly represents `msvc`. Aside from this I do think that the compile-check is valid for MSVC, the warning in that error even suggests to include `<string.h>`, but the test `.c` file already does exactly this... Perhaps the arguments set up by `xwin` and/or the `sccache` wrapper there are incompatible with how we invoke the compiler for this test?
|
I had another look at this by provoking a panic to see if the compiler test is wrong (CC #31) by running what I mentioned in #29 (comment): $ cargo b --target x86_64-pc-windows-msvc -p testcrateI see the same error as @s-nie to Note that such logs, though much more verbose, can also be provoked by passing |
|
I tried #31 and it fixes the issue! Now, there seems to be another, unrelated build error: later followed by This one is not new. Before, I just thought it was a consequence of the I'll close this issue and open a new one. |
|
@s-nie that would not be very helpful. Rather, as requested above, can you provide the rest of the error message when running without #31? As I explained above the part of the error in your original report is correct and expected, and means that the build-test deduced that Perhaps the rest of the message is related (or very likely the same) as/to the problem you are facing now. Likewise, the cut-down 2-lines of warnings/errors won't help us isolate and address the problem either, if we can e.g. not see the rest of the command or context. |
|
Sorry for the misunderstanding. Here is the full output when running |
|
@s-nie yeah that looks to be the same error output all around, just that bit of Is EDIT: Afaik it doesn't correspond to |
A very specific configuration, I know. This may be purely an sccache issue, but maybe it's worth looking into.
My cargo config is:
The sccache version is 0.5.4 and I made sure to clear it beforehand.
Then, running
cargo xwin build --release --target x86_64-pc-windows-msvcinrust-zmqshould be enough to reproduce it, given the system has GLIBC 2.38.Related to #29 which fixes GLIBC 2.38 builds in other cases.
The text was updated successfully, but these errors were encountered: