Cross-compiling with armv7-unknown-linux-gnueabihf is an error

[HaidongZhao]

I modified the source code, compiled through

[jean-airoldie]

First of all there's no need to send screenshots of your GUI, logs will suffice. Secondly submit a PR, if you can't you're gonna have to learn git one day or another. Lastly, I'm not too sure I understand the issue, the strlcpy.c file is used to determine at compile time whether strlcpy is found in the c library. It is normal that it returns and error if the strlcpy is missing, as long at it does not affect the compilation of the actual libzeromq build.

[domenicquirl]

Hi, I'm having the same issue with targeting aarch64-unknown-linux-gnu. I've gathered that the "original" issue was #28 about strlcpy-detection in the original C-library's cmake build system vs. here. I've also followed erickt/rust-zmq#385 to this commit and understood that the fix that was made there to support cross-compilation requires using a version of zeromq-src >= 0.3, which is not yet used by a published zmq release.

However, I then tried to locally patch the zmq-sys dependency to point to the branch from this PR using

[patch.crates-io]
zmq-sys = { git = "https://github.com/MarijnS95/rust-zmq.git", branch = "zeromq-src-0.3" }

This was successful in causing the version of zeromq-rs used during the build to be bumped to zeromq-src-0.3.2+4.3.5 and would compile on the host (as does the older version), but still fails to cross-compile to aarch64 giving

error: failed to run custom build command for `zmq-sys v0.12.0 (https://github.com/MarijnS95/rust-zmq.git?branch=zeromq-src-0.3#1aba88ba)`

Caused by:
  process didn't exit successfully: `/target/debug/build/zmq-sys-6dabaad22ef69b95/build-script-main` (exit status: 1)

  --- stdout omitted
  --- stderr
 /cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.3.2+4.3.5/src/strlcpy.c: In function 'main':
  /cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.3.2+4.3.5/src/strlcpy.c:5:11: warning: implicit declaration of function 'strlcpy' [-Wimplicit-function-declaration]
       (void)strlcpy(buf, "a", 1);
             ^
  /tmp/ccWhvypa.o: In function `main':
  /cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.3.2+4.3.5/src/strlcpy.c:5: undefined reference to `strlcpy'
  collect2: error: ld returned 1 exit status


  error occurred: Command "aarch64-linux-gnu-g++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-4" "-fno-omit-frame-pointer" "-I" "/cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.3.2+4.3.5/vendor/include" "-I" "/cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.3.2+4.3.5/vendor/src" "-I" "/cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.3.2+4.3.5/vendor/src" "-I" "/cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.3.2+4.3.5/vendor/external/sha1" "-I" "/target/aarch64-unknown-linux-gnu/debug/build/zmq-sys-a7433891bd83dba9/out" "-Wall" "-Wextra" "-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" "-DZMQ_HAVE_IPC=1" "-DHAVE_STRNLEN=1" "-DZMQ_HAVE_UIO=1" "-DZMQ_HAVE_STRUCT_SOCKADDR_UN=1" "-o" "/target/aarch64-unknown-linux-gnu/debug/build/zmq-sys-a7433891bd83dba9/out/lib/2d62dae1cebcdbc5-socket_base.o" "-c" "/cargo/registry/src/index.crates.io-6f17d22bba15001f/zeromq-src-0.3.2+4.3.5/vendor/src/socket_base.cpp" with args "aarch64-linux-gnu-g++" did not execute successfully (status code exit status: 1).

The error clearly references main in src/strlcpy.c. I guess (as @jean-airoldie mentions) it is expected that the "test build" of that file would fail on the target if its glibc does not define strlcpy, but it appears that somehow that also causes the entire build to fail.

Appreciate any pointers for where to go next - happy to provide more info and also to run further tests if needed.

[jean-airoldie]

@domenicquirl Open up a separate issue and i'll help you out. My guess is that we need to tweak the cc build so that this expected failure is not causing the build to fail.

[jean-airoldie]

@domenicquirl Also tell me if this branch fixes the issue.

[domenicquirl]

@jean-airoldie thanks for the quick reaction, opened #45 as requested.

[jean-airoldie]

This should be closed by #46.