GCC 4.8 Toolchain

Technical Programming
1

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):

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

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:

As always, help is appreciated. Enjoy!

2

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?

3

The old thread was a bit cluttered anyway, the new main post has all of the links in one place, i say keep this thread.

4

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.

5

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?

6

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.

7

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

8

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.

9

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?

10

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.

11

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 :stuck_out_tongue: to each his own.

12

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?

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.

13

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.

14

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.

15

I’ve never run into this problem because I’ve always cloned onto an NTFS partition - thanks for the bug report.

I’ve always found it easier to make linux deal with windows than windows deal with linux. Windows doesn’t play nice…

16

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.

17

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
18

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.

19

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.

20

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.