GCC 4.9 arm-nilrt-linux-gnueabi toolchain

[AustinSchuh]

Originally Posted by yash101

Thanks! I'm quite new to cross-compiling. I want to have a cross compiler ready for the RoboRIO so I can push my software as soon as possible!

Patrick has been working hard to make gcc 4.9 available on all platforms (mac, linux, windows). Unless you have some specific needs that aren't met by that, you are better off using the provided and supported compiler. 971 is looking forwards to the opposite. Not having to build a custom cross-compiler to get our code to work.

[bb010g]

Originally Posted by AustinSchuh

One of my eventual goals is to set up Clang as well.

As a Functional Freak™ (Haskell) I'd be more than willing to work with you on getting a LLVM backend working. Are you planning on putting or currently have a GitHub repo up?

[AustinSchuh]

Originally Posted by bb010g

As a Functional Freak™ (Haskell) I'd be more than willing to work with you on getting a LLVM backend working. Are you planning on putting or currently have a GitHub repo up?

I've got enough projects lined up, ignoring my day job, that it will probably be next year before I mess with a clang cross compiler. The roboRIO isn't a very arcane backend. It probably just requires the correct compiler options when building the compiler. (softfp ARM backend with NEON)

[CodeYeti]

Originally Posted by AustinSchuh

I've got enough projects lined up, ignoring my day job, that it will probably be next year before I mess with a clang cross compiler. The roboRIO isn't a very arcane backend. It probably just requires the correct compiler options when building the compiler. (softfp ARM backend with NEON)

If I had infinite time I would be trying to get a Rust compiler going for the roboRIO (also if I still had access to hardware). If it was stable, it would be a cool fit with all of its compile-time memory safety guarantees.

It would be insanely useless due to Rust's lack of c++ interop at the current moment, so WPILib wouldn't work, but it would still be a fun project.

EDIT: Actually, with existing toolchains, this might not be all that hard. See ya on the flipside, I'm going in.

EDIT 2: @Patrick:

1. Where did you get those linux headers?
2. How did you compile those libc6 binaries? Bootstrapped GCC?

EDIT 3: Homebrew formulae for OSX folks. https://github.com/mcoffin/homebrew-frc

EDIT 4: Is there a way to make it so I don't have to pass the -B option at runtime to the compile to get it to use the correct binutils instead of my system binutils?

EDIT 5: Rust compiler added to homebrew formulae.

[wireties]

Anyone know if we can get the project files or options NI/WPI used to configure the busybox build? Might be nice to build a new version and add some features here and there.

[Greg McKaskle]

Are you looking for this? https://github.com/ni

Greg McKaskle

[byteit101]

Originally Posted by CodeYeti

If I had infinite time I would be trying to get a Rust compiler going for the roboRIO (also if I still had access to hardware). If it was stable, it would be a cool fit with all of its compile-time memory safety guarantees.

It would be insanely useless due to Rust's lack of c++ interop at the current moment, so WPILib wouldn't work, but it would still be a fun project.

EDIT: Actually, with existing toolchains, this might not be all that hard. See ya on the flipside, I'm going in.

EDIT 2: @Patrick:

1. Where did you get those linux headers?
2. How did you compile those libc6 binaries? Bootstrapped GCC?

EDIT 3: Homebrew formulae for OSX folks. https://github.com/mcoffin/homebrew-frc

EDIT 4: Is there a way to make it so I don't have to pass the -B option at runtime to the compile to get it to use the correct binutils instead of my system binutils?

EDIT 5: Rust compiler added to homebrew formulae.

Oooh... Rust! I though about that awhile ago also...

linux headers and libc6 are from my download script in https://bitbucket.org/byteit101/tool...ilder/src/tip/

Also please update the homebrew formula with my latest updates on the mac folder in the above link. Not sure about the B, but my sources work without that. If you get the headers and libc and gdb all mirroring my mac folder, we might be able to make it official. (Note: I am not the Mouth of Sauron)

Also not Mouth of Sauron: Beta teams should be expecting 4.9 to land sometime early next week if all goes well. Currently migrating our jenkins server to use 4.9.

[CodeYeti]

Originally Posted by byteit101

Oooh... Rust! I though about that awhile ago also...

linux headers and libc6 are from my download script in https://bitbucket.org/byteit101/tool...ilder/src/tip/

Also please update the homebrew formula with my latest updates on the mac folder in the above link. Not sure about the B, but my sources work without that. If you get the headers and libc and gdb all mirroring my mac folder, we might be able to make it official. (Note: I am not the Mouth of Sauron)

Also not Mouth of Sauron: Beta teams should be expecting 4.9 to land sometime early next week if all goes well. Currently migrating our jenkins server to use 4.9.

Yea I fixed that option. It's actually a known problem with both Homebrew's default GCC formula (and also mine). I build a workaround by symlinking the target tuple directory (that should be in /usr/local) between the two kegs.

Updating now (spend the whole day skydiving).

Note that the rust build is currently broken as GYP doesn't correctly detect non-clang compilers on OSX when passed with just the CC environment variable. Looking at workarounds now.

[CodeYeti]

Well, it took many acts of god, but I've gotten the Rust compiler seemingly operational. Now, I don't have any hardware yet (I'm looking for accommodations), but here's an executable that should print "Hello FRC!" for the brave. It would be nice to hear whether it works or not. I've included source, but until I come up with a nice way to build the rust toolchain (I was interrupting the build and calling some targets manually) then I won't bother writing up a guide on how to do so.

A zip file with the source of the executable (and the executable itself so you don't have to build the toolchain) is attached.

[AustinSchuh]

Originally Posted by CodeYeti

It would be nice to hear whether it works or not.

roboRIO:/tmp# ./frc_user_program 
Hello FRC!
roboRIO:/tmp#

[CodeYeti]

Originally Posted by AustinSchuh

roboRIO:/tmp# ./frc_user_program 
Hello FRC!
roboRIO:/tmp#

Holy crap. Thanks. I didn't expect that at all because that's including all of the rust standard libraries (I was expecting to have to strip the standard libraries out due to the way rust's stdlib depends on thread-local storage in weird ways).

Great great great news. I'm going to start looking for hardware I can play around with.

EDIT: I'm getting pretty darn excited by the possibilities with this.

[byteit101]

Originally Posted by CodeYeti

Holy crap. Thanks. I didn't expect that at all because that's including all of the rust standard libraries (I was expecting to have to strip the standard libraries out due to the way rust's stdlib depends on thread-local storage in weird ways).

Great great great news. I'm going to start looking for hardware I can play around with.

EDIT: I'm getting pretty darn excited by the possibilities with this.

FYI following the instructions on the rust wiki worked flawlessly (after changing the triplet) for me, though my compiler command is obscene:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/patrick/code/frc-rust/lib bin/rustc --target=arm-unknown-linux-gnueabi -C linker=arm-frc-linux-gnueabi-g++ test.rs

I did go to the WPI ACM's language lab and ran all the rust code on the RoboRIO. Haven't encountered any errors so far...

[CodeYeti]

Originally Posted by byteit101

FYI following the instructions on the rust wiki worked flawlessly (after changing the triplet) for me, though my compiler command is obscene:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/patrick/code/frc-rust/lib bin/rustc --target=arm-unknown-linux-gnueabi -C linker=arm-frc-linux-gnueabi-g++ test.rs

I did go to the WPI ACM's language lab and ran all the rust code on the RoboRIO. Haven't encountered any errors so far...

Yea the acts of god were all caused by the external build system of the libuv component. It uses gyp, which doesn't play very nicely when your host compiler is clang and target compiler is GNU. It starts mixing up the flags in different areas.

EDIT: Also for some reason the cross compiler envirionment varibales weren't getting passed correctly to GYP. https://github.com/rust-lang/rust/pull/17449

EDIT 2: You need not have multiple rustc installations for all your toolchains, just build one with all your targets, then pass --target at runtime when not building for your host. So you can install frc-rust as just rustc under /usr/local if you want.