Chief Delphi - Alternate GCC Toolchain

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Alternate GCC Toolchain (http://www.chiefdelphi.com/forums/showthread.php?t=109385)

Re: Alternate GCC Toolchain

Quote:

Originally Posted by AlexBrinister (Post 1246006)

@rbmj

From the frc-buildscripts repo, where do the powerpc-wrs-vxworks-* binaries go? /usr/powerpc-wrs-vxworks/bin or /usr/bin?

The standard GCC installation has them hardlinked (not symlinked). I *think* this done so that you can build in a chroot, but don't quote me on that.

Quote:

Going through and C++'ing WPILib sounds like something I'm going to do over the summer lol.

I've previously submitted patches to get rid of warnings (e.g., get rid of typedef enums, etc), but they haven't gotten in. I haven't put these changes into the WPILib repo as I'm trying to track the official builds as closely as possible in order to ensure compatibility and keep changesets easy to apply.

One of the things that's an issue with WPILib in C++11 mode is that with the new constexpr feature, GCC has decided to be more strict about floating point constants being initialized in header files (which is technically not allowed by the standard but has been allowed by GCC for some time). You'll have to make those floating point constants declarations and define them in a .cpp file *or* use a compile-time #ifdef on __cplusplus to use either const or constexpr depending on the standards version.

If I recall correctly, this is the reasoning behind my earlier advice to use -fpermissive when compiling with -std=c++11. I don't believe that changing to gnu++11 solved the problem - I think it had to be the evil fpermissive...

Quote:

Code:

#!/bin/bash



CMAKE="cmake"

TOOLCHAIN_ROOT="/usr/powerpc-wrs-vxworks"

TOOLCHAIN_FILE="$1"

CXX_FLAGS="$2"



exec "$CMAKE" "-DCMAKE_TOOLCHAIN_FILE=$TOOLCHAIN_FILE" "-DCMAKE_INSTALL_PREFIX=$TOOLCHAIN_ROOT" "_DCMAKE_CXX_FLAGS=$CXX_FLAGS" "$3"

A few comments:
1) Since the intention is that FRC uses do not require settings beside the default, I chose to place those values in the script. Your version requires them to put these same arguments (which 99% of the time should be the same) on the command line every time. If they need to override the defaults, they can still use regular old cmake.
2) I also use $@ to allow people to specify their own arguments to cmake, so they don't have to (but can) specify CMAKE_CXX_FLAGS, for example.

The result of this is that a simple call to frcmake alone (with just a directory) is sufficient to build a project, but the user can specify only those flags that they care about in order to configure cmake how they would like. I think this is a superior solution. Since I think the version that's in the packages and on github is better, I think that there already is a standard - the script that lives on github (and thus in the debian repo as well).

Needless to say, you can always put in a pull request on the frc-buildscripts repo, where frcmake lives:
https://github.com/rbmj/frc-buildscripts

But, just because you submit it doesn't mean I'll pull it ;-)

Re: Alternate GCC Toolchain

Quote:

One of the things that's an issue with WPILib in C++11 mode is that with the new constexpr feature, GCC has decided to be more strict about floating point constants being initialized in header files (which is technically not allowed by the standard but has been allowed by GCC for some time). You'll have to make those floating point constants declarations and define them in a .cpp file *or* use a compile-time #ifdef on __cplusplus to use either const or constexpr depending on the standards version.

I still don't entirely understand the difference between the const and constexpr keywords. They seem to be the same to me. But that is a good point.

Quote:

1) Since the intention is that FRC uses do not require settings beside the default, I chose to place those values in the script. Your version requires them to put these same arguments (which 99% of the time should be the same) on the command line every time. If they need to override the defaults, they can still use regular old cmake.
2) I also use $@ to allow people to specify their own arguments to cmake, so they don't have to (but can) specify CMAKE_CXX_FLAGS, for example.

The result of this is that a simple call to frcmake alone (with just a directory) is sufficient to build a project, but the user can specify only those flags that they care about in order to configure cmake how they would like. I think this is a superior solution. Since I think the version that's in the packages and on github is better, I think that there already is a standard - the script that lives on github (and thus in the debian repo as well).

I changed mine because I didn't want to edit the frcmake binary every time I built a project. And I didn't know if people would move the toolchain.cmake file somewhere else (if they wanted it to be project specific or something). So I made those be arguments. But now that you mention $@, there is really no point to my changes because one can just override them anyway. I'm going to change it back because my way was not thought out at all.

Also, I integrated GDB into my latest release. I'm still not quite sure how the Ruby thing works though...

Alex Brinister

Re: Alternate GCC Toolchain

Quote:

Originally Posted by AlexBrinister (Post 1247911)

Or you can use const_cast<char*>(string).

Going through and C++'ing WPILib sounds like something I'm going to do over the summer lol.

Alex Brinster

This is already fixed on the C++11 wiki as based off lateste internal WPI WPILib and will be pushed into WPILib proper next season. I recommend both you pull it in.

Re: Alternate GCC Toolchain

Quote:

Originally Posted by byteit101 (Post 1248672)

This is already fixed on the C++11 wiki as based off lateste internal WPI WPILib and will be pushed into WPILib proper next season. I recommend both you pull it in.

I'll make a new branch on the github repo when I get a chance (probably not today - heading down to watch my old team at VA regional!).

Re: Alternate GCC Toolchain

ANNOUNCEMENT

I'm happy to announce that I have built packages for debian testing (should also work on ubuntu) which are available on the apt repo.

i686 and amd64 packages are available. No other architectures are supported by this binary repo (though feel free to make your own if you really want to run this on your RPi).

Note: Because of some naming changes if you installed my earlier binary packages you MUST uninstall everything *except* wrs-headers-installer before you can install the new packages. An aptitude upgrade will NOT actually upgrade your packages, and may break things!

The /etc/apt/sources.list line is:

Code:

deb http://debian.repo.frc.s3.amazonaws.com wheezy main

The maintainer key may be added using:

Code:

# wget -O - http://debian.repo.frc.s3.amazonaws.com/rbmj.gpg.key | apt-key add -

And the packages may be installed using:

Code:

# aptitude update

# aptitude install gcc-powerpc-wrs-vxworks frc-buildscripts wpilib

New with this release, I have added in working source packages that you can build from, in addition to the sources at my github page. If you plan on using these please read through the wiki and make sure that 1) you understand the process (this requires some outside research) and 2) that you need to be doing this.

The wiki's instructions are also updated for 4.8.0 and no longer require running a development version of GCC.

For more information on binaries, see this wiki page

For more information on compiling from source, see
this wiki page

For instructions on how to build FRC code using this package the best way, see this wiki page.

Re: Alternate GCC Toolchain

Quote:

Originally Posted by rbmj (Post 1253156)

ANNOUNCEMENT

i686 and amd64 packages are available. No other architectures are supported by this binary repo (though feel free to make your own if you really want to run this on your RPi).

Hmm. Installed fine on my amd64 Debian wheezy box; the i686 wheezy box gets this:

Package gcc-powerpc-wrs-vxworks is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'gcc-powerpc-wrs-vxworks' has no installation candidate

Cheers,

Jeremy

Re: Alternate GCC Toolchain

Quote:

Originally Posted by jwhite (Post 1253167)

Package gcc-powerpc-wrs-vxworks is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'gcc-powerpc-wrs-vxworks' has no installation candidate

Looks like I forgot to push the last set of packages to the server... The install should work now.

Re: Alternate GCC Toolchain

Quote:

Originally Posted by rbmj (Post 1253183)

Looks like I forgot to push the last set of packages to the server... The install should work now.

Looks great, thanks!

Re: Alternate GCC Toolchain

Doesn't launchpad provide free hosting for packages (via ppas)? Any reason you are using aws instead?

Re: Alternate GCC Toolchain

Quote:

Originally Posted by codes02 (Post 1255366)

Doesn't launchpad provide free hosting for packages (via ppas)? Any reason you are using aws instead?

I'm on the free tier for AWS. Launchpad does provide free hosting, but only for Ubuntu. It only lets you upload source packages, which are built in a sandbox. Because I'm not sure about the copyright of the gccdist headers, I can't legally redistribute those to the PPA, and the sandbox won't let me download and extract arbitrary files from the internet.

Re: Alternate GCC Toolchain

Hello Everyone,

I've released some alpha windows binaries. These are self-contained windows installer files. Features:

Relocatable Installation
Uninstaller
GCC 4.8.0 and Binutils 2.23.1
CMake 2.8.10.2
WPILib 'Azalea' Post-2013 Code
mingw32-make
Various build scripts

Basically, it contains everything that you need in order to build FRC code.

Release Notes
C++11 mode is not enabled by default - in order to enable it you need to pass -DCMAKE_CXX_FLAGS=-std=gnu++11 (or c++11) when you invoke frcmake

As I do not have a cRIO I am unable to test if this code actually works on a Robot, and am looking for volunteers willing to stress test it to make sure that everything actually works. I am also very interested in people looking to test C++11 features - I highly recommend looking at std::thread, as it promises to make threading much easier.

The installer currently creates registry keys rooted in HKLM and modifies system environment variables (it's safe, I promise), so you will need to have administrator access to install.

Links

Download:
http://firstforge.wpi.edu/sf/frs/do/...tallers.alpha0

Howto (note that on windows, you need to use mingw32-make):
http://firstforge.wpi.edu/sf/go/wiki1288