Re: GCC 4.8 Toolchain
 

First off, an announcement. I've re-released GCC 4.8.2, and builds (for debian jessie amd64 - x86 has to wait until I get my build VM back online) are available on the repo. This one *might* also have std::thread working, but I haven't tested that. New windows builds will come out in the next couple of days when I get a chance to port the changes over and rebuild everything. Changes should be integrated into upstream hopefully before 4.9.

I don't have the source for the new WPILib (is there one? I can't find it on firstforge), so I haven't recompiled that yet. If someone can give me a link that should hopefully be pretty quick.

The reason the binaries are so much larger is because in order to provide all the new features (incl c++11), we use our own libstdc++ instead of VxWorks' included libstdc++. This, along with some symbol trickery, allows us to have all the new features while not breaking all of the rest of the OS. It does cause some symbol bloat though. This is a tradeoff, and you should be aware of it, but I don't think anybody is running up against disk space constraints on the cRIO (are they?).

Re: GCC 4.8 Toolchain
 

Here you go. not sure why they aren't posting it in the normal place: http://first.wpi.edu/FRC/c/update/Release/


Good to know. As far as I know, nobody has ran into the disk constraints yet. The python interpreter builds a dozen or so binaries (each binary module is its own binary), and I think the size is double (ish) what it was previously.

Re: GCC 4.8 Toolchain
 

Thanks, new WPILib is also up on the repo now! GIthub also has updated source.

Re: GCC 4.8 Toolchain
 

New Windows beta is up!

http://firstforge.wpi.edu/sf/frs/do/...stallers.beta1

The windows and debian amd64 builds should be all set up now for developing 2014 competition code! All WPILib fixes have been integrated, C++11 including *multithreading* seems to be working, and I have confirmation of working code on a real cRIO, so hack away.

As always, any bug reports or fixes are appreciated!

Re: GCC 4.8 Toolchain
 

We have run into a problem when using this cross-compile chain. We are able to generate the needed Makefiles using frcmake, and our program compiles, links, and deploys without any errors appearing in terminal. However, when the cRIO boots, the following error is displayed in netconsole and our driver station never shows Robot Code.
Complete netconsole output

We made sure that we have the latest cRIO firmware installed on our cRIO-FRC II. Code deployed from WindRiver is recognized and runs. The program we are attempting to deploy is a very simple example program for one motor.

Running make in debug mode generates this log, which doesn't appear to have any errors. Our CMakeLists.txt is very simple, and based on the one from FIRST Forge

We are using the version of this cross-compile chain from Arch Linux's AUR. We worked on getting this working for about a month before the build season started, but now that the clock is ticking we are under pressure to either get this working this week or return to using WindRiver on Windows Vista.

Any ideas or pointers would be greatly appreciated.

Re: GCC 4.8 Toolchain
 

The package that you're using was released in December. You may need an updated version of the package if you're using a 2014 firmware.

Re: GCC 4.8 Toolchain
 

FYI, whenever you get undefined symbol errors, it's a good idea to run those names through powerpc-wrs-vxworks-c++filt to see what symbols are actually undefined in a slightly more human-readable form.

What you have is actually a problem with your code, not the toolchain.

You declare static variables in the CommandBase class, but you do not provide a translation unit for the compiler to place them in.

In english: Whenever you have something like this in a header:

You need to have something like this in _exactly one_ C++ file:
See this for more: http://www.parashift.com/c++-faq/lin...data-mems.html

As an aside, though I'm glad to help out with issues on the arch toolchain, the Windows and Debian versions are much more mature (and the debian version works on mint, ubuntu, etc.) than the Arch toolchain and as I'm not an arch user I don't actually maintain that toolchain, but I don't release the updates for Arch and only have passing familiarity with its current status. Though I don't endorse using any alternate toolchain, even ucpp, unless you're sure you can handle the lack of support at competition, I would say that the debian and windows versions are significantly more competition ready.

Re: GCC 4.8 Toolchain
 

Thank you so much. We even looked at those variables because of the error message, but no one picked up on our omission.

Also, your caution about Arch is noted. I don't think we'll be using the Arch chain at the actual competition (unless things go very well), but we have a few very old computers that it runs rather well on that we've given out to the programmers for developing and testing.

Re: GCC 4.8 Toolchain
 

I have been using the Arch Linux version of the toolchain for over six months and have submitted most of the bug fixes for it (I'm basically the official unofficial maintainer). My team and I have put it through extensive testing and used it at an off-season competition, so I'm confident that it's at least as stable as the Windows distribution, which my team also uses.

I submitted a pull request to the official package maintainer with the C++11 fixes and am working on one for the WPILib update, but he is pretty slow at merging any fixes and updates I submit. Furthermore, he usually forgets to publish them to the AUR. I may suggest taking over as the maintainer, but hopefully it won't take too long.

Nevertheless, I made a diff of the WPILib versions and there were no changes made that impact network communications or anything else vitally important (which is unfortunate considering I've found fatal, albeit obscure, bugs in NetworkTables); WPILib now uses standard typedefs for data types instead of the strange ones it used to define internally, a PIDGet method was added to the AnalogChannel class, and some calls to LiveWindow were changed. The old version also runs on the updated firmware based on what I've tested.

Re: GCC 4.8 Toolchain
 

I stand corrected. You have been instrumental in stabilizing the windows toolchain as well, so thanks for that also!

I've long been slightly annoyed at the lack of openness in the development in WPILib, and I'm on record on that in several places here. Right now it is very much an example of the cathedral model of open source development. But I'll leave that for other threads.

Re: GCC 4.8 Toolchain
 

Just an update:

The debian repo is now updated with i386 builds.

AMD64 and i386 both have tests indicating that std::thread and friends are working, so go do awesome multithreaded stuff!

Re: GCC 4.8 Toolchain
 

I have also created a wiki page for walking through any issues people have when migrating code from previous years (or this year from WindRiver) over to this toolchain. Please let me know if you need to make any changes other than those described in the document to get your code to work. Thanks!

The page can be found here: http://firstforge.wpi.edu/sf/wiki/do...n/wiki/Porting

Re: GCC 4.8 Toolchain
 

All,

One more announcement: I've generated the doxygen documentation for WPILib, available here. This is intended as a convenience (so we don't *all* need to generate documentation).

There's a lot in WPILib that's undocumented though - so as teams come across undocumented areas, please document them (if you have the necessary knowledge), and make a pull request. I'll regenerate the documentation, and everyone can immediately benefit.

I've also decided that I'm willing to throw out binary compatibility with stock WPILib, since that makes no sense as we always statically link. So, I'm willing to incorporate new features as long as they won't break any existing code at the source level. Any new additions also need to be worth the cost (extra code) - I'm not a fan of feature creep.

Re: GCC 4.8 Toolchain
 

I haven't tried debugging a binary built with this toolchain yet, but it looks like I'm going to play that game tomorrow. Some questions:

• I suspect I'll need to tell cmake to build in debug mode, correct? Are some symbols still there in release mode?
• Can/should I still use wind river to connect to the cRio and debug the program that way? Or is the only way to do it is using gdb? Or doesn't it matter
• If I use wind river to debug, and build the program in debug mode, will it be able to do source level debugging, or are the symbols incompatible?

Thanks in advance!

Re: GCC 4.8 Toolchain
 

When I do release builds, I have to append -s to the build flags manually in order for 10MB of symbols to be stripped from the executable. I only see a 2MB difference between debug and release builds otherwise. Based on that, I assume the necessary symbols are still included in release builds.

My intuition tells me it doesn't matter whether one uses Wind River or GDB for debugging since the executable's symbols are being munched the same way with either build environment; one would expect identical behavior. I know that GDB was used in conjunction with wireshark a while ago to reverse-engineer the WDB protocol; therefore, powerpc-wrs-vxworks-gdb has worked properly before. My last (failed) attempt at using it was over 6 months ago, but the remote target crash I experienced may have either been fixed since then or been entirely my fault.

I have some guesses on this, but I can't with good confidence share them since I don't know how Wind River does its source level debugging. byteit101 (Patrick) may know more about it.