Can't compile for armv6 or v7

[Lindenk]

Possibly a duplicate of #516.

I've tried the suggested workaround of adding -march armv6 to the compile flags to no avail. I'm not entirely convienced this is the same problem though as it seems to be failing when looking for some assembly related file and not finding it.

I'm currently using the x-tools arm_unknown_linux_gnueabi toolchain in the arch linux aur.

If anyone has a workaround, it would be appreciated!

https://ptpb.pw/FEUl

[Lindenk]

It looks like I can compile correctly directly on a raspberry pi 3. Is there someone different about cross-compiling for this?

[andrewtj]

That panic suggests the arm-linux-gnueabi-gcc executable isn't available

[Lindenk]

I think I've found the problem. Every other crate compiles just fine, ring is the only exception but it looks they are correctly using the compiler defined in ~/.cargo/config for the target architecture. Ring seems to be expect it as arm-linux-gnueabihf-gcc instead of the one defined under ~/.cargo/config.

The workaround for now seems to be symlinking the name it expects and adding it to path. I would propose this be fixed in a later version of ring though.

[briansmith]

Hmm. Do you have $CC set? If so, unset it; if not, set it. Please share your ~/.cargo/config here.

[Lindenk]

It looks like setting $CC (previously unset) does work. Here's my ~/.cargo/config:

[target.arm-unknown-linux-gnueabihf]  
linker = "/usr/x-tools/x-tools7h/arm-unknown-linux-gnueabihf/bin/arm-unknown-linux-gnueabihf-gcc"

Ok, I just realized that it's also the linker. Well, I suppose that isn't a bug then, sorry about that. Hopefully this will be useful for anyone else looking for an answer.

[briansmith]

Great, thanks! I am curious, you said other project compile fine even when $CC is not set. Could you list the names of one or more crates that have C code that cross-compile correctly but don't require $CC to be set? I'd like to change ring to work like they do, if possible.

[sanmai-NL]

@Lindenk: also curious about the answer to @briansmith's question.

[Lindenk]

I suppose I haven't used a crate with native C until now. Although I do seem to have another problem where ring is passing -m64 to a 32-bit compiler. https://pastebin.com/fHBZYXTp

[pietro]

TARGET = Some("x86_64-unknown-linux-gnu")

Are you passing a --target option to cargo?

[Lindenk]

Yes. Curiously, it seems to work if I first build it natively then cross compile. If I remove the entire target directory and attempt to cross compile, it fails.

[mckaymatt]

I am having the same problem trying to cross-compile with cargo build --target armv7-unknown-linux-gnueabihf. The error shows that internally target it set as TARGET = Some("x86_64-unknown-linux-gnu").

My horrible workaround is to run the build first with CC unset until the build fails. Then I set CC and continue the build. Otherwise I run into the issue with ring is passing -m64 to a 32-bit compiler.

This may be related to rust-lang/cargo#4741

[AzureMarker]

@mckaymatt @Lindenk I was also having the -m64 problem. I found that setting TARGET_CC to the cross compiler and CC to something like cc will let you compile in one go.

[briansmith]

@Mcat12 Thanks, that sounds promising.

Concretely, what can I do to make cross-compiling easier or automatic? When I started the ring project I was regularly cross-compiling it by setting CC and other environment variables. However, recently I am working on projects that primarily target x86_64 so I don't do much cross compiling now and I don't have much time to investigate or improve things. I encourage more people cross-compiling to chip in with suggestions and/or PRs. Only in the last few days have I had an opportunity to start updating ring again. If people make PRs that improve this situation I'll do my best to merge them expediently.

[AzureMarker]

@briansmith Thanks for your interest. I have not previously looked into too much of the fine details of library build scripts, especially in this type of situation where there's different compilers for parts. However, it sounds very interesting. I guess, my first suggestion is to look at what other libraries are doing, though I'm not sure how applicable that is to this one. I'll look into your build scripts and see what I can come up with.

I ran into this issue through compiling Rocket 0.3.5 which requires ring 0.11.0. I haven't checked your latest release notes for if you've worked on cross compiling, mostly for a lack of knowing where they are located ;). The project I'm working on is part of Pi-hole, where we're experimenting with using Rust in the upcoming HTTP module of the FTL daemon we develop in C. We compile for most of the common platforms such as x86_64, arm, armhf, aarch64, etc. You can see our CI on Travis and our Travis config on GitHub. Finding a more automatic way to cross compile will help both of us :).

[briansmith]

It seems like cross automatically sets CC so maybe the solution to this problem is to document that cross should be used? We could optionally also document other manual steps that people have taken to make it work.

I don't think we should try to automate the setting of CC or the detection of the cross-compiler beyond what the cc crate does.

[shijunti19]

me too

[briansmith]

Thanks for the information here. It helps understand the difficulties people have.

Here are the most common problems people have:

1. They don't set TARGET_CC and cc-rs's heuristics don't pick the right compiler. Solution: Set TARGET_CC before cargo build.
2. They set CC instead of TARGET_CC. This sometimes works accidentally when cross-compiling, but it creates problems when build dependencies need to use a C compiler. Solution: Set TARGET_CC instead of CC.
3. Trying to compile for Thumb-only target. This is issue Remove unused #define's related to md32_common.h #81

I would like cross-compiling to work better and I'm actively investigating how to do that. But, keeping this issue open won't help, so I'm closing it.