Cross-compilation with `cargo xwin` fails when sccache is enabled with GLIBC>=2.38

[s-nie]

A very specific configuration, I know. This may be purely an sccache issue, but maybe it's worth looking into.

  --- stderr
  /home/sven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.2.6+4.3.4/src/strlcpy.c(5,11): error: call to undeclared library function 'strlcpy' with type 'unsigned long long (char *, const char *, unsigned long long)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
      (void)strlcpy(buf, "a", 1);
            ^
  /home/sven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.2.6+4.3.4/src/strlcpy.c(5,11): note: include the header <string.h> or explicitly provide a declaration for 'strlcpy'
  1 error generated.

  error occurred: Command "sccache" "clang-cl" "-nologo" "-MD" "-O2" "-Z7" "-Brepro" "-m64" "--target=x86_64-pc-windows-msvc" "-Wno-unused-command-line-argument" "-fuse-ld=lld-link" "/imsvc/home/sven/.cache/cargo-xwin/xwin/crt/include" "/imsvc/home/sven/.cache/cargo-xwin/xwin/sdk/include/ucrt" "/imsvc/home/sven/.cache/cargo-xwin/xwin/sdk/include/um" "/imsvc/home/sven/.cache/cargo-xwin/xwin/sdk/include/shared" "-I" "/home/sven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.2.6+4.3.4/vendor/include" "-I" "/home/sven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.2.6+4.3.4/vendor/src" "-I" "/home/sven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.2.6+4.3.4/vendor/src" "-I" "/home/sven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.2.6+4.3.4/vendor/external/sha1" "-I" "/home/sven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.2.6+4.3.4/vendor/external/wepoll" "-I" "/home/sven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.2.6+4.3.4/vendor/builds/deprecated-msvc" "/GL-" "/EHsc" "-DZMQ_BUILD_TESTS=OFF" "-DZMQ_USE_CV_IMPL_STL11=1" "-DZMQ_STATIC=1" "-DZMQ_USE_BUILTIN_SHA1=1" "-DZMQ_HAVE_WS=1" "-DZMQ_IOTHREAD_POLLER_USE_EPOLL=1" "-DZMQ_POLL_BASED_ON_POLL=1" "-D_WIN32_WINNT=0x0600" "-DZMQ_HAVE_IPC=1" "-Fo/home/sven/rust-zmq/target/x86_64-pc-windows-msvc/release/build/zmq-sys-5c768056df47cfca/out/lib/c7dc53c602ec3030-wepoll.o" "-c" "--" "/home/sven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.2.6+4.3.4/vendor/external/wepoll/wepoll.c" with args "clang-cl" did not execute successfully (status code exit status: 1).

My cargo config is:

[build]
rustc-wrapper = "sccache"

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-msvc in rust-zmq should be enough to reproduce it, given the system has GLIBC 2.38.

Related to https://github.com/jean-airoldie/zeromq-src-rs/pull/29 which fixes GLIBC 2.38 builds in other cases.

[MarijnS95]

That is rather suspicious, the target file zeromq-src-0.2.6+4.3.4/src/strlcpy.c(5,11) is the test file that we use to determine if the target supports strlcpy. It has #include <string.h> at the top so it's rather curious that it requests this.

Perhaps sccache cannot function properly as a test-compiler passthrough? Or clang-cl doesn't understand the parameters. I'll comment in #29 because I think there's one place where there's a check if the host environment is gnu in order to invoke the gcc compiler check, rather than the target environment.

[MarijnS95]

Cooked up a fix so that this test script shouldn't be invoked in the first place:

https://github.com/jean-airoldie/zeromq-src-rs/pull/31

It was guarded by gnu host flags (i.e. those used when compiling this build script to run on your Linux machine) instead of looking at the target flags when that build script is eventually run natively on the Linux machine produce output for a cross-compilation.

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 string.h... but we include that already?!

[jean-airoldie]

@s-nie Please tell us if #31 that was merged into master fixed your issue.

[MarijnS95]

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 https://github.com/jean-airoldie/zeromq-src-rs/pull/29#discussion_r1327737067:

$ cargo b --target x86_64-pc-windows-msvc -p testcrate

I see the same error as @s-nie to stderr. This is normal, and exactly what the compile test is for (let's disregard correctness of clang-cl's message for now). Instead, what's interesting is the panic/error that occurs after it, which is what triggers cargo to print this build scripts' stdout, environment variables, and stderr.

Note that such logs, though much more verbose, can also be provoked by passing -vv to cargo build.

[s-nie]

I tried #31 and it fixes the issue! Now, there seems to be another, unrelated build error:

warning: clang-16: warning: unknown argument ignored in clang-cl: '-fvisibility=hidden' [-Wunknown-argument]

later followed by

warning: clang-16: error: no such file or directory: '/wd4668'

This one is not new. Before, I just thought it was a consequence of the strlcpy issue, but fixing that did not fix this issue.

I'll close this issue and open a new one.

[MarijnS95]

@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 strlcpy is not available. However, something after that is failing which causes cargo to print all of stderr including this harmless message.

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.

[s-nie]

Sorry for the misunderstanding. Here is the full output when running cargo xwin build --release --target x86_64-pc-windows-msvc on commit 4b873ae0aaa60f8ce3fef493130ab3c5588b4903 of rust-zmq, with sccache enabled.

out.txt

[MarijnS95]

@s-nie yeah that looks to be the same error output all around, just that bit of stderr from the compile test that's "clobbering" the logs.

Is sccache adding that /wd4668? It doesn't show up in the ToolExecError.

EDIT: Afaik it doesn't correspond to -Wno-unused-command-line-argument either, but to -Wundf and I don't immediately see response files that might be turning this on from elsewhere?