GCC 4.8 Toolchain [Archive]

rbmj

16-05-2013, 13:38

Hi all,

Since it appears that CD has cleaned out old topics, I'm opening a new thread so that people with issues with the GCC 4.8 toolchain can get support.

Please post any future questions regarding this project in this thread.

Features:

- GCC 4.8, with all it's awesomeness including caret diagnostics, improved error messages, better optimizations, etc.

- C++11 support. While this is a 4.8 feature, it deserves its own bullet point. Note that this is not yet enabled by default on all platforms due to some issues with updating WPILib.

- Native builds for linux, with alpha native builds for OSX and Windows (including a .msi made using WIX, so you know it's legit)

- All-around awesomeness

If you want to help out with development, please do! Read the wiki, look at the code, and post here!

A few links:

FirstForge page for the project, including wiki with a decent amount of information to get up to speed on the project:

http://firstforge.wpi.edu/sf/projects/c--11_toochain

Wiki page on that project page that details how to get and install. Note that, being territorial, I'm going to recommend my repos over Patricks ;). In all seriousness though, mine are stable for cRIO development, but Patrick's repos offer various features in different stages of development, which I'll pull in once I'm convinced they're stable.

http://firstforge.wpi.edu/sf/wiki/do/viewPage/projects.c--11_toochain/wiki/BinaryInstall

Wiki page on how to build and install with FRCMake (the IMHO easiest and best way to build these projects):

http://firstforge.wpi.edu/sf/wiki/do/viewPage/projects.c--11_toochain/wiki/UsingCMake

Link to the Windows Installer:

http://firstforge.wpi.edu/sf/frs/do/viewRelease/projects.c--11_toochain/frs.windows_installers.alpha0

Note that once you install the windows installer, you have FRCMake et al installed automatically.

Link to the old topic to find old discussion - it's long but well worth reading if you want to learn more (second only to the wiki):

http://www.chiefdelphi.com/forums/showthread.php?t=109385

WPILib repository (open development, unlike closed-off upstream):

https://github.com/rbmj/wpilib

All of the code/buildscripts can be found either on the team's bitbucket:

https://bitbucket.org/frc-cpp11

or some is still on my github page:

https://github.com/rbmj/

As always, help is appreciated. Enjoy!

Kimmeh

17-05-2013, 12:24

Since it appears that CD has cleaned out old topics

I have nothing to comment on the rest of the post, but on the main page of the subforum, there's a box titled "Display Options" Perhaps the thread you're looking for hasn't been posted in for over a month?

Anupam Goli

18-05-2013, 02:49

rbmj

19-05-2013, 12:08

I have nothing to comment on the rest of the post, but on the main page of the subforum, there's a box titled "Display Options" Perhaps the thread you're looking for hasn't been posted in for over a month?

Ah. I didn't happen to see that box. Though the purpose of that box seems rather dubious given that the forum is paginated... appears redundant to me. Maybe I'm just bitter because it made me look stupid.

Links in one place is also rather good. After a thread gets to ten pages long it starts to get hard to sift through everything...

I apologize to the community for the double post.

William Kunkel

14-09-2013, 18:46

This is a bit of an old thread, but I figured I'd try asking here first. Does the Windows installer support C++11? I tried to compile an old project with
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
in my CMakeLists.txt, but compiling caused screens and screens of errors, from my code, but also from WPILib (Mostly "error: 'constexpr' needed for in-class initialization of static data member") and from "mingw\powerpc-wrs-vxworks\include\c++\4.8.0\bits\" (Mostly "error: unable to find numeric literal operator 'operator"" xLU'" from random.tcc). Have I made a mistake, or does the windows installer not yet support C++11?

rbmj

15-09-2013, 11:23

The current builds do not. When I get around to it I'll rebuild it with C++11 support.

If you build from source with the latest version of everything, you should not have this problem.

William Kunkel

15-09-2013, 11:58

Cool. Now I just need to figure out how I'm gonna do that crazy build process for Windows.

rbmj

15-09-2013, 13:01

It's quite crazy. Hopefully it all makes sense to you. I'm going to work on making those crazy makefiles a bit more readable. If you need any help let me know - or request edits to the documentation that I can pull.

Basically, you set up a cross mingw on linux and get the toolchain working there. Because building GCC through cygwin sucks, you end up building everything on linux and then packing it all up on windows (as I did *not* want to mess with wine). I recommend going onto a machine with a dual boot and mounting the NTFS partition from linux and then running the install there.

If the build process looks strange, that's because it is. There's some bugs in the GCC build that prevent the target libraries (i.e. libgcc and libstdc++ for vxworks) from building through mingw. It's due to some stupid configure issues for a canadian cross where it tries to run the host compiler to build the target libraries even though it's not native to the build platform. What it's supposed to do is build two compilers, but it doesn't seem to do this by default. The solution: Just do the whole build process twice.

I ran into a lot of issues (wix in particular liked to crash), but the build process is fairly stable, if long and involved. Again, if you need any help, I'm here.

William Kunkel

15-09-2013, 14:20

rbmj

15-09-2013, 18:20

In the FIRSTForge wiki's requirements for building for windows, one of the linux requirements is "Working linux toolchain", does that mean just a working GCC install, or a working install of the powerpc-wrs-vxworks toolchain?

Yes.

You need to have gcc-powerpc-wrs-vxworks installed because part of the build process is building wpilib on linux. This is built with frcmake et al, so you need to have all of that installed. I didn't want to have the build process install things halfway through/have to run as root, so I just made it a predependency.

Since the linux binaries work and are relatively stable, I don't see this as a big problem. Additionally, building from source under linux is now (relatively) easy - no more patching and crap, and the everything is documented.

rbmj

17-09-2013, 13:18

I updated the wiki to make it slightly more clear.

Building on windows is still a mess. Maybe when I get a bit more motivation and rebuild everything I'll make those make files a bit less ugly.

My build virtual machines were on an external hard drive that broke a couple of months ago, so that might take a while - I have a lot less free time than I would like.

The next release should have a few incremental improvements, but no major changes. Biggest improvements will include a removal of some ugly symlink cruft on linux (WARNING- may break existing installations, but will make distributing libraries much nicer), an upgrade to gcc-4.8.1 including a small vxworks-specific patch for thread specific data finalizers (I doubt anybody used this), and hopefully a more stable windows build. Patrick got debugging functioning but I don't know how he did it, can't test it (no cRIO), and therefore won't release it until he says it's ready to go. Those who can actually work through these things, feel free to look at the repos and test things out.

At the end of this, I'm hoping that a community can develop where teams can have their own libraries and share them with the first community such that I can incorporate some other team's library by doing a 'sudo aptitude install frcfoobar' and then adding 'find_package(frcfoobar)' to my CMakeLists.txt and be done.

I personally find using CMake to be much nicer than the existing IDE-based toolchains (a CMakeLists.txt that will work for 99% of teams is <10 lines long, but gives you a much nicer build experience IMHO), but if anybody is scared by a 10 line text file, I can work on better IDE integration (otherwise it doesn't seem worth the effort to me - you can still use eclipse to edit the files if you want). I do ask how you're a c++ programmer if you can't deal with a short and simple text file though :P to each his own.

William Kunkel

17-09-2013, 17:56

rbmj

17-09-2013, 23:44

Alright, so I have made several attempts to build, and have come to an error I really don't understand:

In file included from /home/will/frc-cpp11/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/libgcc2.c:27:0:
/home/will/frc-cpp11/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../gcc/tsystem.h:87:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^

I definitely have the standard library, I can find stdio.h with the locate command (actually I can find several), but this still keeps happening. Any insights?

You should have stdio.h in /usr/powerpc-wrs-vxworks/sys-include. If that is true then something else is going on, in which case I'll look into it. I can't make promises on when that will happen though - I'm a double major at USNA, so free time isn't exactly plentiful.

By the way, you might want to recommend against building in a VM shared folder, as it makes symlinks not work correctly and broke my build.
I was not aware of this; thanks for pointing that out.

If you're trying to build w/o windows, it *is* theoretically possible. However I haven't tried 1) because I have windows and it isn't too big of a pain and 2) I've heard rumors that wix sometimes builds bad msi-s when run through wine.

William Kunkel

21-09-2013, 02:03

Sorry for the lack of response, I've been a bit busy. I tried a few other things (building as root, creating a new vm in virtualbox instead of vmware because vmware was being buggy), but this problem still recurs. The file is definitely where it ought to be, but the build can't seem to find it. Additionally, the windows-toolchain-environment repo seems to have some permissions issues, for example prepare.sh does not have execute permissions, so I've tried building after running chmod -R a+rwx . in the directory as well. It fixed the permissions issues, but the issue with stdio.h remains.

rbmj

23-09-2013, 11:25

William Kunkel

23-09-2013, 22:01

I don't suppose you can detail your exact build configuration (distro, version, file location, partition)? I'm doing this all in a virtual machine, so it's no problem to build a new one to test things out, and if it works under that maybe I can narrow down where this bug is.

William Kunkel

29-09-2013, 12:16

Update: I tried the build again, this time on Ubuntu 13.04 and cloning onto an NTFS formatted flash drive. It again failed because it was unable to find <stdio.h>. For reference, here's the last command it attempted to execute:

/media/frc-build/windows-toolchain-environment/win32/linux-build-gcc-4.8.0/./gcc/xgcc -B/media/frc-build/windows-toolchain-environment/win32/linux-build-gcc-4.8.0/./gcc/ -B/mingw/powerpc-wrs-vxworks/bin/ -B/mingw/powerpc-wrs-vxworks/lib/ -isystem /mingw/powerpc-wrs-vxworks/include -isystem /mingw/powerpc-wrs-vxworks/sys-include -g -O2 -O2 -nostdinc -I `case "/$(MULTIDIR)" in */mrtp*) echo /h ;; *) echo /media/frc-build/windows-toolchain-environment/win32/install-prefix/mingw/powerpc-wrs-vxworks/wind_base/target/h ;; esac` -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../.././gcc -I/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc -I/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/. -I/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../gcc -I/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../include -DHAVE_CC_TLS -o _ashldi3.o -MT _ashldi3.o -MD -MP -MF _ashldi3.dep -DL_ashldi3 -c /media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS

Then the errors that result from running that command:

/bin/bash: MULTIDIR: command not found
/bin/bash: MULTIDIR: command not found
In file included from /media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/libgcc2.c:27:0:
/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../gcc/tsystem.h:87:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
make[3]: *** [_muldi3.o] Error 1
make[3]: *** Waiting for unfinished jobs....
/bin/bash: MULTIDIR: command not found
In file included from /media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/libgcc2.c:27:0:
/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../gcc/tsystem.h:87:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
In file included from /media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/libgcc2.c:27:0:
/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../gcc/tsystem.h:87:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
make[3]: *** [_lshrdi3.o] Error 1
make[3]: *** [_negdi2.o] Error 1
In file included from /media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/libgcc2.c:27:0:
/media/frc-build/windows-toolchain-environment/win32/gcc-4.8.0/libgcc/../gcc/tsystem.h:87:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
make[3]: *** [_ashldi3.o] Error 1
make[3]: Leaving directory `/media/frc-build/windows-toolchain-environment/win32/linux-build-gcc-4.8.0/powerpc-wrs-vxworks/libgcc'
make[2]: *** [all-target-libgcc] Error 2
make[2]: Leaving directory `/media/frc-build/windows-toolchain-environment/win32/linux-build-gcc-4.8.0'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/media/frc-build/windows-toolchain-environment/win32/linux-build-gcc-4.8.0'
make: *** [stmp-build-gcc-target] Error 2

calcmogul

30-09-2013, 17:30

I haven't been able to get the linux compiler in linux-build-gcc-4.8.x to build either under most circumstances. I've found that with both the commands in linux.mk and the PKGBUILD files on Arch Linux, it builds when --prefix=/usr is specified in configure, but not when any other prefix is specified. I've tried messing around with --with-sysroot=, --with-headers=, and --disable-bootstrap, but they all cause various errors at different points in the build process.

With the default configure options, it determines that /lib/cpp is how the C preprocessor should be run when building libiberty.a and fails. I applied a patch for vxworks mkdir in libgcov that comes with the Arch Linux PKGBUILD, which got it past that but caused compiler errors while building libstdc++:

/tmp/gcc-test-build/build/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:228:62: error: invalid type in declaration before ';' token
typedef __atomic_base<uintmax_t> atomic_uintmax_t;

I got the windows side of the toolchain working though with the Wix Toolset, after I tweaked Toolchain.wxs and windows.mk. I'll submit a pull request for it and some bug fixes for bugs in the todo list later today.

calcmogul

01-10-2013, 19:03

In regards to the stdio.h no such file error, try moving the target stmp-gccdist-all to the top of the make targets in linux.mk under "all:". gcc's configure is looking for stdio.h in $(PREFIX)/$(TARGET)/sys-include, which expands to the directory /mingw/powerpc-wrs-vxworks/sys-include, but that folder isn't there until the target stmp-gccdist-all copies sys-include and wind_base there from the zip archive it downloads.

William Kunkel

05-10-2013, 21:37

Sadly, rearranging the order of the make targets like that had no effect on the build; it still failed because it was unable to find stdio.h. However, mingw/powerpc-wrs-vxwors/sys-include exists. The build fails during stmp-build-gcc-target. Looking at the configuration, it seems like it should be searching for my actual system headers at this step, because it's building a cross-compiler from the host to powerpc-wrs-vxworks, and so should be using the native gcc and the native system headers. It should just copy the headers from mingw/powerpc-wrs-vxworks/sys-include to $(PREFIX)/include, if I'm reading the GCC docs correctly.

calcmogul

06-10-2013, 01:33

stmp-build-gcc-target is, from what I can tell, bootstrapping a cross compiler to build the target libraries such as libstdc++, libgcc, etc. In the last few days, I was able to get the target libraries to compile and have made some working installers with Wix. I had to patch the gcc source and the headers coming from gccdist. The toolchain works with the exception of the "Relocation value does not fit in 24 bits" error on 8 slot cRIOs, which is due to libraries linked in which are not being built with -mlongcall; on Arch Linux, it was libstdc++ and libgcc, but I'm still trying to find the library responsible for this particular failure. The final installation doesn't have anything in /mingw/include and has no gccdist headers in /mingw/powerpc-wrs-vxworks/include (only c++ standard includes and the WPILib folder). I've submitted a pull request to the windows-toolchain-environment repo which has the patch files and other fixes. These are my modified gccdist recipes:

stmp-gccdist-scripts: stmp-gccdist-directories
- cp -R $(GCCDIST_ARCHIVE_BASE)/host $(WIND_BASE)
+ cp -dpr --no-preserve=ownership $(GCCDIST_ARCHIVE_BASE)/host $(WIND_BASE)
touch stmp-gccdist-scripts

stmp-gccdist-headers: stmp-gccdist-directories
- cp -R $(GCCDIST_ARCHIVE_BASE)/target/h/. $(TOOL_DIR)/sys-include
- cp -R $(GCCDIST_ARCHIVE_BASE)/target/h/wrn/coreip/. $(WIND_BASE)/target/h
+ cp -dpr --no-preserve=ownership $(GCCDIST_ARCHIVE_BASE)/target/h/. $(WIND_BASE)/target/h
+ cp -r $(WIND_BASE)/target/h/. $(TOOL_DIR)/sys-include
+ cp -r $(WIND_BASE)/target/h/wrn/coreip/. $(WIND_BASE)/target/h
touch stmp-gccdist-headers

In short, I recommend seeing if some of the patches and modifications to linux.mk in the pull request help. Try changing the gccdist copying first though since that fixed a lot of weird errors for me like the C preprocessor being identified as "/lib/cpp" and failing a sanity check.

rbmj

22-10-2013, 09:36

I lost my repo key for the debian repository, so I started over from scratch - I'm sorry if this affects anyone. The URL should be the same but you need to import the new key (again at the same URL).

Much improved amd64 debian builds (now based on jessie), including one last patch into GCC with the upgrade to GCC 4.8.2, better handling of the include files, and fixes for the environment variable system, is now up. If there are any issues let me know.

x86 debian to come soon. Sorry for all you RPM/TGZ/Arch folks, but debian testing is still the only officially supported distribution. Other debian based distributions should be binary compatible as most of GCC is statically linked.

Finally, new windows builds are here (http://firstforge.wpi.edu/sf/frs/do/viewRelease/projects.c--11_toochain/frs.windows_installers.beta0). Many thanks to mathmogul for his major improvements to the build system! The build process is completely automated on my system. frcmake && mingw32-make works to build my teams' old code on my windows box. However, I can't test anything. I need to double-check the build logs w/r/t mlongcall.

Windows toolchain (linux component) build specs:

Debian testing (jessie)
Build conducted on shared ext3 partition (I've also gotten it to work on FAT32)
All packages updated
amd64 physical machine
Build conducted in various locations.
I do have the regular linux toolchain installed from the packages - this might be necessary to get all the headers to play nicely. If things aren't working, try installing (at least) wrs-headers.

I realized that I had made some symlinks in special places on my filesystem to make the build work previously. However, these are no longer necessary, and I have successfully build without them.

As a second announcement, if any of you maintain libraries for FRC, I'll host your packages on the repo! A few points:

If you want a package to be a part of the ecosystem, it should fit in. I request that you use frcmake to build your package and provide find_package() config files, but this is not a requirement.
Check out WPILib (https://github.com/rbmj/wpilib) for example debian/rules, debian/control, CMakeLists.txt, *.cmake, etc. files. 99% of porting over your library can be a simple copy-paste of the WPILib stuff.
I would love for new teams to be able to look at what kind of cool libraries the community has developed, aptitude install them, and then integrate them into their own projects by changing just two lines of their CMakeLists.txt. This is the goal.

I know that FIRST likes having IDE integration, but when a real world CMakeLists.txt (https://github.com/rbmj/612-code/blob/master/CMakeLists.txt) is only 8 lines long, which can be easily copied/pasted off the wiki, and it makes it VERY easy to use other teams' libraries, and installation doesn't require sitting around on your computer all day dealing with the WindRiver installation process and license keys... I think this is a superior workflow.

I know that Patrick made some significant headway on integrating GDB, so if people want to try and get that to work (check the bitbucket and the wiki), you might be able to get somewhere.

William Kunkel

04-11-2013, 20:50

Do you know the status of libstdc++ is on this architecture/compiler? I just tried to use std::copysign (http://en.cppreference.com/w/cpp/numeric/math/copysign) and got back 'copysign' is not a member of 'std' I'm 95% sure that I don't have any errors in my code causing that, so I'm forced to conclude that it has not yet been implemented in the library. Is there some sort of listing of what parts of libstdc++ have been completed for C++11 on this architecture?

rbmj

03-12-2013, 07:48

We're currently working on figuring out what features for c++11 on the library side are available.

A lot of things that seem like they should work don't, and I have to dive into the libstdc++ code to see what's going on...

Sorry for the long wait on reply!

virtuald

22-12-2013, 00:21

For anyone who is interested, I've created a Vagrant-based VM configuration that you can run and get a easy to use virtual machine to do your building on. The current configuration sets up the apt configuration and installs the binary packages as recommended on the wiki, and FRCMake seems to work correctly.

It's an Ubuntu 12.04 image, but the binaries seem to work just fine there. I've built the core of RobotPy with it, and the build succeeded without any problems -- though, I haven't ran it on the cRio yet.

Get it from the github repo (https://github.com/virtuald/frc-gcc-vm.git).

SoftwareBug2.0

22-12-2013, 01:32

virtuald

22-12-2013, 08:29

How hard are the listed version requirements? Is that just what you used or are those minimums? Vagrant 1.4 was only released last week.

True, I'll change the docs. Vagrant 1.2+ should work. There are various bugs in vagrant that I've ran into over time, so I'd recommend 1.3.5 if you're not going to use 1.4.

SoftwareBug2.0

24-12-2013, 01:18

True, I'll change the docs. Vagrant 1.2+ should work. There are various bugs in vagrant that I've ran into over time, so I'd recommend 1.3.5 if you're not going to use 1.4.

I think there are some other additional requirements to make this work. Here's what I got:

Bringing machine 'default' up with 'virtualbox' provider...
[default] Clearing any previously set forwarded ports...
[Berkshelf] This version of the Berkshelf plugin has not been fully tested on this version of Vagrant.
[Berkshelf] You should check for a newer version of vagrant-berkshelf.
[Berkshelf] If you encounter any errors with this version, please report them at https://github.com/RiotGames/vagrant-berkshelf/issues
[Berkshelf] You can also join the discussion in #berkshelf on Freenode.
[Berkshelf] Updating Vagrant's berkshelf: '/home/eric/.berkshelf/default/vagrant/berkshelf-20131223-3824-141h9iv-default'
[Berkshelf] Using frc-gcc-vm (0.1.0)
[Berkshelf] Using apt (1.7.0)
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'starting, running'. The machine is in the
'poweroff' state. Please verify everything is configured
properly and try again.

If the provider you're using has a GUI that comes with it,
it is often helpful to open that and watch the machine, since the
GUI often has more helpful error messages than Vagrant can retrieve.
For example, if you're using VirtualBox, run `vagrant up` while the
VirtualBox GUI is open.

This is with virtualbox 4.3.6 and vagrant 1.4.1 on 32-bit Ubuntu 12.04. The Virtualbox GUI suggested a problem with VMX instructions but I checked and those are enabled on my system. It appears that the guest system is 64-bit. Perhaps the host is required to be as well.

Also, it might be helpful to note that the "vagrant up" should be done in the directory of the checkout. This is probably obvious to someone who has used vagrant before but I suspect most people haven't.

virtuald

24-12-2013, 14:37

I think there are some other additional requirements to make this work. Here's what I got:

Bringing machine 'default' up with 'virtualbox' provider...
[default] Clearing any previously set forwarded ports...
[Berkshelf] This version of the Berkshelf plugin has not been fully tested on this version of Vagrant.
[Berkshelf] You should check for a newer version of vagrant-berkshelf.
[Berkshelf] If you encounter any errors with this version, please report them at https://github.com/RiotGames/vagrant-berkshelf/issues
[Berkshelf] You can also join the discussion in #berkshelf on Freenode.
[Berkshelf] Updating Vagrant's berkshelf: '/home/eric/.berkshelf/default/vagrant/berkshelf-20131223-3824-141h9iv-default'
[Berkshelf] Using frc-gcc-vm (0.1.0)
[Berkshelf] Using apt (1.7.0)
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'starting, running'. The machine is in the
'poweroff' state. Please verify everything is configured
properly and try again.

If the provider you're using has a GUI that comes with it,
it is often helpful to open that and watch the machine, since the
GUI often has more helpful error messages than Vagrant can retrieve.
For example, if you're using VirtualBox, run `vagrant up` while the
VirtualBox GUI is open.

This is with virtualbox 4.3.6 and vagrant 1.4.1 on 32-bit Ubuntu 12.04. The Virtualbox GUI suggested a problem with VMX instructions but I checked and those are enabled on my system. It appears that the guest system is 64-bit. Perhaps the host is required to be as well.

Also, it might be helpful to note that the "vagrant up" should be done in the directory of the checkout. This is probably obvious to someone who has used vagrant before but I suspect most people haven't.

Good points. I'll add those notes to the documentation also. :)

You're right, it's a 64-bit guest. If you switch the box name (and the name in the URL) to 'precise32', then you'll get a 32-bit guest. However, it appears that there is not a build of gcc available for 32-bit in the repository.

You might try older versions of virtualbox to see if they have the same problems, or google about the mixed host problem.

virtuald

26-12-2013, 02:13

So I got RobotPy to build successfully using the frcmake in the VM I made, but I've noticed that some of the output files are significantly larger than the binaries I built with Wind River. In particular, all of the SIP-based binaries seem to be much larger than they were previously, double or triple the size. Looking at the objdump output, there seems to be a lot more symbols in the new binaries compared to the old binaries, but it seems to be mostly C++ gibberish and duplicate symbols.

My suspicion is that something isn't getting stripped/munched from the object file properly, but I can't tell. For comparison purposes, I've attached the nivision.pyd binary output files if someone wants to compare them.

Additionally, I've checked in the CMake build files for RobotPy into the gcc48 branch of https://github.com/robotpy/robotpy.git .

rbmj

07-01-2014, 10:26

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.

So I got RobotPy to build successfully using the frcmake in the VM I made, but I've noticed that some of the output files are significantly larger than the binaries I built with Wind River. In particular, all of the SIP-based binaries seem to be much larger than they were previously, double or triple the size. Looking at the objdump output, there seems to be a lot more symbols in the new binaries compared to the old binaries, but it seems to be mostly C++ gibberish and duplicate symbols.

My suspicion is that something isn't getting stripped/munched from the object file properly, but I can't tell. For comparison purposes, I've attached the nivision.pyd binary output files if someone wants to compare them.

Additionally, I've checked in the CMake build files for RobotPy into the gcc48 branch of https://github.com/robotpy/robotpy.git .

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?).

virtuald

07-01-2014, 10:49

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.

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

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?).

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.

rbmj

07-01-2014, 12:02

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

rbmj

07-01-2014, 18:19

New Windows beta is up!

http://firstforge.wpi.edu/sf/frs/do/viewRelease/projects.c--11_toochain/frs.windows_installers.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!

restouffer

07-01-2014, 19:37

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.

* Loading FRC_UserProgram.out: FRC_UserProgram
Warning: module 0xebb940 (FRC_UserProgram.out) holds reference to undefined symbol _ZN11CommandBase2oiE.
Warning: module 0xebb940 (FRC_UserProgram.out) holds reference to undefined symbol _ZN11CommandBase5motorE.
(unloading partially loaded module FRC_UserProgram.out)
...FRC_UserProgram failed to load.

Complete netconsole output (http://pastebin.com/bhVhtxiT)

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 (https://github.com/FRC2539/command-based) for one motor.

Running make in debug mode generates this log (http://pastebin.com/SjNXwbck), which doesn't appear to have any errors. Our CMakeLists.txt (http://pastebin.com/9dvzNZJq) is very simple, and based on the one from FIRST Forge (http://firstforge.wpi.edu/sf/wiki/do/viewPage/projects.c--11_toochain/wiki/UsingCMake)

We are using the version of this cross-compile chain from Arch Linux's AUR (https://aur.archlinux.org/packages/frc-wpilib-git/). 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.

virtuald

07-01-2014, 19:50

We are using the version of this cross-compile chain from Arch Linux's AUR (https://aur.archlinux.org/packages/frc-wpilib-git/).

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.

rbmj

07-01-2014, 19:51

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:

class foo {
static int bar;
};

You need to have something like this in _exactly one_ C++ file:

int foo::bar = 2;

See this for more: http://www.parashift.com/c++-faq/link-errs-static-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.

restouffer

07-01-2014, 20:10

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.

calcmogul

08-01-2014, 06:15

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.

rbmj

08-01-2014, 07:47

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 stand corrected. You have been instrumental in stabilizing the windows toolchain as well, so thanks for that also!

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.
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.

rbmj

13-01-2014, 11:13

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!

rbmj

13-01-2014, 11:39

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/viewPage/projects.c--11_toochain/wiki/Porting

rbmj

17-01-2014, 08:13

All,

One more announcement: I've generated the doxygen documentation for WPILib, available here (http://rbmj.github.io/wpilib/). 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.

virtuald

08-02-2014, 00:46

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!

calcmogul

08-02-2014, 01:35

I suspect I'll need to tell cmake to build in debug mode, correct? Are some symbols still there in release mode?

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.

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

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.

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?

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.

rbmj

10-02-2014, 16:31

First off, I haven't done any debugging with this toolchain, so take anything I say with a grain of salt. Patrick probably has the best understanding of how this all works - I suggest you try and contact him, and then document your procedure so others can replicate.

There are a few things I can say though.

1) There might be a problem using WindRiver for debugging, as the stock toolchain uses gcc 3 and this toolchain is gcc 4. There are ABI incompatibilities between the two versions, but I do not know if these incompatibilities have a significant impact on debugging. It's worth a try though.

2) There is a decent amount of information on the Wiki, but the debugging section is more notes-style than tutorial-style, so it might take a while to figure out. If you do figure it out and have something to add, we would of course appreciate that.

3) You might need to add -g in CMAKE_CXX_FLAGS - I don't recall if CMake puts it there by default.

virtuald

10-02-2014, 17:15

I had mixed results with debugging, but I was finally able to find the bug. I quickly found that I couldn't get gdb to work -- it hung at 'enabling debug mode', and so I didn't waste much time with that. However, I was running the command from a linux VM running on an OSX host, so take that with a grain of salt.

By setting the CMAKE_BUILD_TYPE to Debug, I was able to do Debugging via Wind River. I had to manually load the symbols and source code before it would work, but when I clicked pause or whatever it would show local variables and the stack trace and such. Oddly enough, when everything was hung at a semTake call, Wind River could not successfully show the entire stack, but would only show the OS stack pieces, and couldn't show the stack back into the task's code.

I was finally able to get a full stack trace via netconsole. By entering 'tt <taskid>' at the netconsole prompt, it was able to provide a full stack trace, and I was able to identify my hung threads... which ended up being a nasty bug in NetworkTables (forum post if you're interested (http://www.chiefdelphi.com/forums/showthread.php?t=126102)).