Build script fails when cross-compiling to aarch64-unknown-linux-gnu
#45
Comments
|
@jean-airoldie I patched with the fix you mentioned in #42 (comment), which looked promising in that the |
|
@domenicquirl Could you run your build again with |
|
Based on the output you provided so far, the specific commands that cause the build to fail seem to be the following. I wonder if the |
|
Its also possible that the |
|
Ok so I passed Compiler OutputThe more extensive output made me notice the lines which also appear for I vaguely remembered coming across erickt/rust-zmq#356 while looking for existing issues in There are some stray warnings that remain: but the build itself succeeds and all my tests run successfully. For completeness, I also tried with only the additional |
|
The I'm trying to figure out why the build was working without the error in CI, but not when cross-compiling locally. I thought that if the issue is about while our CI image has version |
One strategy that we could employ is trying to force c++98 on other targets (in CI for instance). If the build succeeds, then I guess we could conclude that this is target specific, and we could set the c++11 flag appropriately based on the target. |
|
I tried forcing c++98, and I can reliably reproduce your issue. Interestingly the build succeeded on macos & windows, but failed on ubuntu. On windows, the c++98 flag is not recognized therefore ignored. I'm guessing the flag is silently ignored on macos. |
|
This seems to indicate that c++11 is required currently. If the fragments are indeed optional and we could pinpoint how to disable them, then this would fix this issue, without require c++11, which would be ideal. |
|
Based on the CMakeLists.txt from The |
|
Now if i recall correctly, the oldest supported platform on linux supported by rust is centos7, which is uses gcc version On macos, im not so sure. Based on this issue it seems that the oldest supported OS version is |
|
On second thought, the ideal solution in this case would just be to copy libzmq's cmake approach, testing whether the c++11 flag is supported, if so we add it. I'll look into it tomorrow. |
|
@domenicquirl Alright so I looked into libzmq & CMAKE's source code and cooked up a simple test to check whether c++11 is supported, if so it is automatically enabled. This is the same behavior then what libzmq does, so it would not technically be a breaking change. Please tell me if this PR solves your issue. |
|
Thanks again for looking into this. Good to hear that you were able to reproduce the issue!
That makes sense to me since I'd expect non-Linux OSes to use different compilers and therefore also different C libraries? This part of the
is probably none. By default,
I'll be able to try that out tomorrow! |
|
@jean-airoldie it works! 🎉 With your PR branch, the result is the same as with the env var: I'm getting the what I called "stray warnings" above, but everything compiles and runs successfully! |
|
Guess it's time to revive erickt/rust-zmq#386 then so this actually ends up in the real |
|
Cool.
Could you run again with |
|
It seems to just be running |
|
Ah right thanks. Very strange, doesn't give us much clue about it source however. |
|
I don't know what emits this command, but it doesn't seem to come from this library. Its possible that this is a valid command on some platform, but i couldn't find much information. For now I will simply ignore this warning, and i'll merge the PR. Then, I'll do a release with a minor bump, since this shouldn't be a breaking change. |
|
Alright I published v0.3.3+4.3.5 with this fix. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Coming from #42:
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-sysdependency to point to the branch from erickt/rust-zmq#386 usingThis 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
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.
Full compiler output
The text was updated successfully, but these errors were encountered: