GCC 4.9 arm-nilrt-linux-gnueabi toolchain [Archive]

yash101

05-09-2014, 10:49

I have never cross-compiled before, so I am a newbie. When you use GCC and try to compile an application for another platform like the PPC in the cRIO, do you still have access to the full C++ STL library? Also, are there some libraries like pthread available?

I have the GNU GCC compiler to cross-compile for the RasPi, but I don't know if it will compile my application, which uses pthread and libx11.

Thanks!

AustinSchuh

05-09-2014, 16:30

What C library did you use? Just glibc? And where did you snag the kernel headers?

I was feeling really lazy, and found a pre-built tool-chain. Compiling GCC takes a while. We will be spreading more information (and filing bug reports) as part of the beta test, and this will be part of it. I'd like to get some more experience with everything before spreading info.

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

byteit101

05-09-2014, 19:51

We are currently updating our toolchain for GCC 4.9, which will (hopefully, almost positive) be the official C++ compiler for 2015. Its not yet done (I'm actually waiting for GCC to compile on launchpad as I type this), but we are hoping to let some beta teams test it soon (week or so?).

What C library did you use? Just glibc? And where did you snag the kernel headers?

The C library much match the one on the roborio (which is glibc irrc. We are currently just copying them off the image). The kernel headers are normal kernel headers, which can be snagged by something like this: https://bitbucket.org/byteit101/toolchain-builder/src/0b343d5f9c3c7910b6ff08ce90d35027cf06f744/get_linux.sh?at=default

I have never cross-compiled before, so I am a newbie. When you use GCC and try to compile an application for another platform like the PPC in the cRIO, do you still have access to the full C++ STL library? Also, are there some libraries like pthread available?

I have the GNU GCC compiler to cross-compile for the RasPi, but I don't know if it will compile my application, which uses pthread and libx11.

Thanks!
Depends on the platform. C++STL is anywhere that C++ compiles, but pthread is not always. Its on the RoboRIO, but not the cRIO. libx11 is not on the RoboRIO as there is no output display for X to run on.

Shameless plug: Anyone interested in maintaining arm-linux-gnueabi packages for non .deb-based linux should contact me. If the given platform already has binutils 2.24 and gcc 4.9.1, you only need to package the header files and so libs.

CodeYeti

08-09-2014, 19:27

We are currently updating our toolchain for GCC 4.9, which will (hopefully, almost positive) be the official C++ compiler for 2015. Its not yet done (I'm actually waiting for GCC to compile on launchpad as I type this), but we are hoping to let some beta teams test it soon (week or so?).

The C library much match the one on the roborio (which is glibc irrc. We are currently just copying them off the image). The kernel headers are normal kernel headers, which can be snagged by something like this: https://bitbucket.org/byteit101/toolchain-builder/src/0b343d5f9c3c7910b6ff08ce90d35027cf06f744/get_linux.sh?at=default

Depends on the platform. C++STL is anywhere that C++ compiles, but pthread is not always. Its on the RoboRIO, but not the cRIO. libx11 is not on the RoboRIO as there is no output display for X to run on.

Shameless plug: Anyone interested in maintaining arm-linux-gnueabi packages for non .deb-based linux should contact me. If the given platform already has binutils 2.24 and gcc 4.9.1, you only need to package the header files and so libs.

As I'm only an alum for a team, I have access to neither hardware nor the actual images so I didn't know what library headers I should be using. I was having a REALLY hard time getting glibc to build with a bootstrap version of GCC though, which is probably due to my relative inexperience with toolchain building. Any tips on getting building a bootstrap version of GCC that will actually build glibc?

EDIT: Also is there a preview version of wpilib i could be using?

calcmogul

09-09-2014, 21:01

I was having a REALLY hard time getting glibc to build with a bootstrap version of GCC though, which is probably due to my relative inexperience with toolchain building. Any tips on getting building a bootstrap version of GCC that will actually build glibc?

I've built an arm-linux-gnueabi cross compiler before on Arch Linux by using the instructions here: http://www.archlinuxuser.com/2013/07/how-to-install-arm-linux-gnueabi-gcc-on.html. Although, the packages don't build the correct version of glibc among other things. If you use another distribution, you could run the shell commands in the PKGBUILDs yourself.

EDIT: Also is there a preview version of wpilib i could be using?

There's a git repository for the 2015 WPILib at https://usfirst.collab.net/sf/sfmain/do/viewProject/projects.wpilib, but it's not publicly viewable.

taichichuan

09-09-2014, 22:00

You should be able to use the Linaro GCC 4.9 toolchain on a Linux box. I'm using it now for my other ARM platforms on my Linux Mint 17 box.

CodeYeti

09-09-2014, 23:24

I've built an arm-linux-gnueabi cross compiler before on Arch Linux by using the instructions here: http://www.archlinuxuser.com/2013/07/how-to-install-arm-linux-gnueabi-gcc-on.html. Although, the packages don't build the correct version of glibc among other things. If you use another distribution, you could run the shell commands in the PKGBUILDs yourself.

There's a git repository for the 2015 WPILib at https://usfirst.collab.net/sf/sfmain/do/viewProject/projects.wpilib, but it's not publicly viewable.

What does one have to do to get access?

calcmogul

10-09-2014, 01:02

What does one have to do to get access?

To get read access, I submitted an account creation request on the login page and it got approved by an administrator eventually.

CodeYeti

11-09-2014, 12:05

wt200999

12-09-2014, 12:19

While this might not be exactly what you are looking for, NI has a full openembedded build system set up as well as their fork of the linux kernel on their github here: https://github.com/ni
(https://github.com/ni)

There are a couple of other cool things on their github as well if you look around.

byteit101

14-09-2014, 00:00

I'm still planning on rolling my own toolchain, but for the information of others I just found someone building Debian/Ubuntu packages here (https://launchpad.net/~byteit101/+archive/ubuntu/frc-toolchain).

wow, google let that get out fast... That is the current WPI WIP official 2015 toolchain set (for debian/ubuntu) Please note that we just are starting to release this to beta teams (like 5pm today), so bugs are expected. There are other bits not found in this repository (mainly WPILib and all the FRC-specific libraries) so you can't build robot programs with it yet if you are not an beta tester. Please don't report bugs if you aren't a beta tester, there are several broken things I know about already and its only been the first few hours. I don't need hundreds of the same bug reports...

Also if you are a beta tester and you haven't heard of this yet: we are rolling this out slowly due to the large breakage this could cause. Don't panic.

yash101

16-09-2014, 23:36

Excuse me for this extremely newbie question:
Just a couple days ago, I made an ARM cross compiler for my RasPi. They both are ARM based, so right away, it seems as though the RPi executables will be compatible with the cRIO. However, aren't there differences in the machine code between the different subsets of ARM? Would they prevent my executables from running?

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!

AustinSchuh

17-09-2014, 12:44

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

18-09-2014, 00:31

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

18-09-2014, 12:39

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

19-09-2014, 12:48

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:

Where did you get those linux headers?
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

20-09-2014, 18:02

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

20-09-2014, 19:42

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

Greg McKaskle

byteit101

20-09-2014, 22:48

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:

Where did you get those linux headers?
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/toolchain-builder/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 (https://plus.google.com/110981030061712822816/posts/KaSKeg4vQtz))

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

21-09-2014, 03:13

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

linux headers and libc6 are from my download script in https://bitbucket.org/byteit101/toolchain-builder/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 (https://plus.google.com/110981030061712822816/posts/KaSKeg4vQtz))

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

22-09-2014, 17:24

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

22-09-2014, 17:41

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

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

CodeYeti

22-09-2014, 17:48

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

22-09-2014, 21:06

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

22-09-2014, 22:10

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.