Closed jean-airoldie closed 1 year ago
@MarijnS95 I added a fallback for glibc dynamic compilation where we try to compile a simple c program linking against strlcpy in
@MarijnS95 Alright, now the lib does a compilation check to see if strlcpy is in the std lib, like you originally proposed. At least now I understand the reasoning. Could you please tell me if this fixes your issue, since I don't have an easy way to replicate it.
I tested the build on the latest glibc and works. Also a friend who had ready an environment for cross-compilation tested it and works there too,
@oblique Cool thanks for the help. I'll wait on @MarijnS95 to merge since he opened the issue.
@oblique @MarijnS95 Thanks again for your time. I'll do a release.
Thanks a lot for the quick fix for this!
EDIT: Disregard the following. It looks like the sccache
was not correctly invalidated. Works fine without it.
I noticed that the error still appears in cross compilation on Linux for Windows.
Any idea why this would be? I have a vague memory of platform checks not working as expected because the build script still compiles on Linux and then runs "on Windows," or something like that. So I sometimes have to check the platform with std::env::var("CARGO_CFG_TARGET_OS").as_deref() == Ok("windows")
.
The output of cargo xwin build --release --target x86_64-pc-windows-msvc
in rust-zmq
is:
--- 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).
@s-nie Can you create an example repo that reproduces the issues?
I updated the comment, it was an issue with sccache
. Sorry for the confusion.
I'm still confused :) Is there an issue when sccache
is used in general? Or the issue was because of your setup?
So I thought it was just an issue with cache invalidation in sccache. It keeping the pre-fix configuration around would have explained this. But I just tried again with sccache
cleared and enabled, and the same issue came up again. My cargo configuration looks like this:
[build]
rustc-wrapper = "sccache"
The sccache version is 0.5.4.
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.
Would you mind creating a new separate issue, because this is hard to follow since this is a pull request thread.
Fixes https://github.com/jean-airoldie/zeromq-src-rs/issues/28
@MarijnS95 This approach checks
glibc
version. This results in better compilation speed than the CMAKECheckCXXSymbolExists
approach which involves compiling multiple times. Please tell me if it fixes your issue.This should work for any platform that uses
glibc
.Open questions:
target_env
== "" as being valid for historical reasons so I wonder if some GNU target might have that field empty. https://doc.rust-lang.org/reference/conditional-compilation.html#target_env.