Build for OpenPandora (softfloat)

[ReactorScram]

I'd like to be able to cross-compile Rust programs for my Pandora as I discussed on Reddit. glibc says it is version 2.9 so hopefully it may be possible.

[MagaTailor]

You could try building a pandora target rustc on some armhf machine by simply modifying the arm target to suit you needs. This way you could use the method described here along with one of the prebuilt arm snapshots.

If you require a specific cpu you could even do:

let mut base = super::linux_base::opts();
    base.cpu = "your_cpu_arch".to_string();

at line 14th and an additional 15th of arm_unknown_linux_gnueabi.rs

[warricksothr]

I'll start playing around with some things. The glibc of 2.9 is a bit tricky. Do you know if the Open Pandora is running a version of Linaro?

I don't think softfp will be a major issue, if I can get an LLVM to compile on a glibc 2.9 system. It'll have to be LLVM in my experience as gcc was having issues compiling the latest rust on the raspbian image. Honestly I'm more concerned with whether rust will even compile on glibc 2.9. I think the official build bots compile against glibc 2.13.

[ReactorScram]

So I just realized 9 is actually a smaller number than 13. Oopsy.

Is Linaro a distro? I think the Pandora's distro Super Zaxxon is forked from Angstrom Linux.

[warricksothr]

That's good to know. I'm currently trying to build a toolchain with glibc 2.9 with what I know about the Rust requirements. Once I have that I'll actually start work on trying to compile Rust. With the hopeful end result being libraries with a target triple of arm-unknown-linux-gnueabi. With those libraries it should be possible to cross compile Rust from any development machine to the desired target.

Linaro is a company that focuses on linux kernel and software development for ARM boards. https://en.wikipedia.org/wiki/Linaro. Honestly I was thinking of Angstrom when I typed Linaro, I have a little experience with Angstrom and was just hoping to find a platform I could start with for the crosscompiling container. Honestly at this point it looks like I might start back with Debian Lenny, compile glibc 2.9 along with Clang/LLVM and CMake, and try from there.

[warricksothr]

Apologies, I've been away on business. I'll be back on the 15th and pickup from there on the soft-float build test.

[warricksothr]

Still no major progress. That's not a bad sign though, It's just the I have a lot to catch up on now that I'm back from the business trip. Hoping to have some time this weekend to figure out what is stopping the build.

[MagaTailor]

Not related to this issue but there's been a major breakage (libc crate) on arm platforms (affecting x86 android too) but the good news is at least cargo can be built again since a few hours ago :)

You probably noticed the scripts couldn't build it while you were away...

[MagaTailor]

BTW, could you point us to the script used to build the stage0 snapshots? Thx!

EDIT:
It's provided in mk/snap.mk, e.g:

make snap-stage3-H-arm-unknown-linux-gnueabihf

[Church-]

Any news on this issye?

[warricksothr]

I don't have a clean build script for making the snapshots for an entirely new system. I've been bootstrapping them by hand on my x86 desktop using qemu cross platform binary tools.

Between the holidays and work I haven't made much progress on this issue. If anyone would like to take a crack at it, let me know and I'll try to provide as much info as I can about the whole build process.

[Church-]

Well, I'll take all the info you can give. Probably won't make progress, but why not.

[MagaTailor]

@pandora_users, @pranith ( I saw issue rust-lang/rust#28467)
If you know how to set up and use qemu-user you could try the following on your pandora box to get an idea if the build process could work natively:

Download the latest armhf stage0 snapshot and put the uncompressed rustc binary in /tmp/stage0/, renaming it to rustc.bin. Create a one-line wrapper script (make it executable) in /tmp/stage0/bin/, named rustc with the following content:

/usr/bin/qemu-user-arm /tmp/stage0/rustc.bin -C target-cpu=cortex-a8 -L path_to_your_/stage0/lib/rustlib/arm-unknown-linux-gnueabi/lib "$@"

After unpacking a nightly rust source snapshot, you could run configure normally in the top-level directory:

./configure --enable-local-rust --local-rust-root=/tmp/stage0/ --target=arm-unknown-linux-gnueabi --build=arm-unknown-linux-gnueabi

and see how far it gets. Note the -L option in the wrapper script.

I'd already suggested modifying the arm target which might be necessary to set the correct processor architecture. Additionally arm-unknown-linux-gnueabi.mk needs to be modified as well - see an example for another soft-float platform.

If it doesn't work you could try cross-bootstrapping after supplying the correct glibc version and so on.

EDIT 2015-12-27
Good news guys - the latest qemu-user (tested on x86 emulating x86_64) is able to handle all rlibs' (crates) compilations which means the method I described should work on any platform that has a working qemu-user using a corresponding stage0 snapshot.

The only imperfection at the moment: qemu sometimes fails to create the stamp file at the end (uncaught target signal 11) so the user has to do that manually, e.g touch stamp.rustc_privacy as needed and reissue VERBOSE=1 make.

[MagaTailor]

BTW, the OP @ReactorScram only wanted to cross-compile for the pandora (soft float -> arm-none-eabi) which shouldn't pose a problem if the following is true:

This reddit comment from 2 months ago promised officially distributed rlibs for some arm targets which should be enough once you've installed an appropriate cross gcc and multilib toolchain.

[ReactorScram]

Glad to see some progress was made, I had assumed there wouldn't be enough support. (And soon the Pyra will come out with OMAP5 and hardfp)

Compiling on the Pandora itself is okay, but cross-compiling is better since it'll be faster. I just never had any luck with installing cross-compilers.

[ssokolow]

Since this is still pretty much the top result for cross-compiling Rust to the Pandora...

I've only started to experiment but, so far, I get cross-compiled results that seem to work perfectly well on my Pandora with the following steps:

# Step 0: Set up one of the C cross-compilers from https://pandorawiki.org/Cross-compiler
# (I'm using Sebt3's Yactfeau)

# Set up Rust to target LLVM's version of the triple my C cross-compiler targets
rustup target add arm-unknown-linux-gnueabi

# Tell Cargo where to find my Pandora-targeting GCC for the final link against libc
cat >> ~/.cargo/config << EOF
[target.arm-unknown-linux-gnueabi]
linker = "/home/ssokolow/opt/pandora-dev/arm-2011.09/bin/pandora-gcc"
EOF

# Open up a simple Rust project and ask cargo to cross-compile
cd ~/src/rip_media
cargo build --release --target=arm-unknown-linux-gnueabi

# Confirm that I actually got an ARM binary and test it
file target/arm-unknown-linux-gnueabi/release/rip_media
scp target/arm-unknown-linux-gnueabi/release/rip_media 192.168.0.8:/home/ssokolow/
ssh 192.168.0.8 ./rip_media

(NOTE: While I tested this, I actually use a slightly more involved release.sh which, after running cargo, calls strip --strip-unneeded, sstrip, and upx --ultra-brute to make the most of my space... as well as optionally using nightly to build with opt-level='z' and alloc_system.)

[ReactorScram]

After I made my comment last night, I was finally able to cross-compile a C++ library using Clang + the Pandora's own GCC linker from the Code::Blocks PND. (The cross-compilers on the wiki look hideously complex and I'm couldn't get any of them to work)

I was not able to find the right GCC cross-linker in my desktop's repos, but if I can just get Rust to cross-compile a .o file, I should be able to link it the same way, right?

[ssokolow]

I tried something similar at one point. The command-line that Rust outputs in the failure message when it tries to use cc doesn't work when you re-run it with the command changed to the cross-compiling gcc.

I didn't try very hard to fix it since I wanted to figure out why the proper solution wasn't working (I got Cargo.toml and ~/.cargo/config mixed up), but I remember it being something about a path not being found.

[ReactorScram]

@ssokolow - Got it working using your method with Yactfeau linker. Very easy to setup now. Thanks for all the help!