Re: GCC 4.8 Toolchain
 

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.

Re: GCC 4.8 Toolchain
 

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:
Then the errors that result from running that command:

Re: GCC 4.8 Toolchain
 

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

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.

Re: GCC 4.8 Toolchain
 

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.

Re: GCC 4.8 Toolchain
 

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.

Re: GCC 4.8 Toolchain
 

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:

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.

Re: GCC 4.8 Toolchain
 

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

Re: GCC 4.8 Toolchain
 

Do you know the status of libstdc++ is on this architecture/compiler? I just tried to use std::copysign and got back 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?

Re: GCC 4.8 Toolchain
 

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!

Re: GCC 4.8 Toolchain
 

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.

Re: GCC 4.8 Toolchain
 

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.

Re: GCC 4.8 Toolchain
 

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.

Re: GCC 4.8 Toolchain
 

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

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.

Re: GCC 4.8 Toolchain
 

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.

Re: GCC 4.8 Toolchain
 

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 .