Having difficulty setting up cross-compiling

help
1

Greetings all.

So I'm relatively new to Rust, and in particular I'm not all that familiar with the tools yet. I've been trying to set up a bare-metal environment, but things don't seem to be working as expected. I've tried playing around a bit myself to see if I can make it happen, but truth is I'm just not familiar enough with the systems at play.

I'm using Fedora 27 as a host environment, and targeting a Raspberry Pi 2 (or, more accurately, the raspi2 QEMU machine). I've been using a seemingly well-referenced blog (post) as my base, and trying to adapt the information to the platform I'm using. It didn't go quite as expected, so I've tried also integrating other information from around the place; I think the main other resource I tried was the Xargo README.

So here's where I've gotten to:

  • Installed Xargo and the rust-src component;
  • Installed the nightly-armv7-unknown-linux-gnueabihf toolchain (the closest one I can figure to arm-none-eabi);
  • Added rlibc as a dependency;
  • Created a arm-nx-eabihf.json target file, based on the armv7-unknown-linux-gnueabihf target given by rustc --print target-spec-json;
  • Tried running xargo +nightly build --target=arm-nx-eabihf;

Xargo complains it can't find the crate for core, and notes that the target may not be installed. Now, my understanding is that Xargo should be building core from the Rust source that I am led to believe I obtained earlier (the rust-src component), but it doesn't seem to be doing such a thing.

I've also tried just using the armv7-unknown-linux-gnueabihf target, but this resulted in a huge amount of unknown symbols from the linker. Searching for one of these symbols turned up references to gcc_eh, but searching for that library turned up nothing useful at all. That's a slightly different problem, though I wouldn't be surprised if this problem showed itself again.

The source, configuration files and Makefiles that I'm using can be found on GitHub (commit), if anyone wants to take a browse.

I am happy to provide any extra information. Any help is much appreciated.

2

Looks fine, I just wonder if xargo supports the +nightly shorthand like rustup. Do you get the same error if you set the default toolchain to nightly and run xargo without +nightly?

1 Like
3

Huh. Seems like that works, though not sure why it produced that particular error. :thinking: Thanks for helping find that.

Now I've got a couple linker errors again. Much shorter this time, but I recognise those symbols as those mentioned in the original post:

build/arm-nx-eabihf/debug/libplatform.a(platform-c2aca85040789948.platform0.rcgu.o):(.ARM.exidx.text.platform_main+0x0): undefined reference to `__aeabi_unwind_cpp_pr1'
build/arm-nx-eabihf/debug/libplatform.a(platform-c2aca85040789948.platform0.rcgu.o):(.ARM.exidx.text.rust_begin_unwind+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'

... this resulted in a huge amount of unknown symbols from the linker. Searching for one of these symbols turned up references to gcc_eh, but searching for that library turned up nothing useful at all. That’s a slightly different problem, though I wouldn’t be surprised if this problem showed itself again.

Called it, I guess. :wink:

4

I think you probably want to set panic=abort in your target spec, I can't remember the exact syntax though.

1 Like
5

Aha! Thank you dearly, my good sir and/or madam! :tada:

For reference, the syntax is:

{
    // ...
    "panic-strategy": "abort",
    // ...
}

One final question: what does this actually do on panic? I figure it would call some kind of abort() function, any idea what that might be? I figure I'll need to handle that at some point.

If you happen to also have any idea how to set up unwinding in this situation, I may want that as well at some point. That said, not an urgent thing and I can probably sit down and figure that out when I come to it.