Re: Alternate GCC Toolchain
 

I did the same thing, luckily, the first thing I did was check the config.log!

Regardless, ironically, I've got this stuff running on my mac via a manual install much better than I do on debian with the packages, but I'd love to help with development, and I want to stay current so I'm trying to switch over. Right now, theres something broken where its not finding the C++ includes (i.e. #include <string> won't work, etc) and I have no idea why. If anybody has run in to this, I'd appreciate a tip. Debugging as you're reading.

Also, just as a thought, since your debian package for wpilib has a builddep for cmake, and AFAIK, just invokes it, why don't you just use CPack? Seems like that would be a little bit cleaner solution, but that's just me.

EDIT: Still having that issue with the packages. I'm going to try the packages you built and see if that makes a difference. Just to make sure, I've been installing them in this order:
Any help is appreciated.

Re: Alternate GCC Toolchain
 

Never seen that one... thanks for all your work testing/fixing/debugging!

Because CPack, though easy, doesn't handle dependencies, metadata, and maintainer scripts as nicely as the native toolchain does.

Re: Alternate GCC Toolchain
 

Alright. I didn't know it didn't have the capability to handle dependencies.

Also, I'm still having that same issue with not finding the C++ includes. <see above>

EDIT:If I'm asking a ton of questions, it's because this is more of a learning experience than a hardcore project for me :D.

EDIT 2: I installed the versions of the packages from your dropbox, and I'm still getting the c++ headers problem. The headers are in the exact same place as they are on my mac, where the whole system works (manual installs, no packages or anything).

Re: Alternate GCC Toolchain
 

Stupid question: do the directories specified by `powerpc-wrs-vxworks-gcc -print-prog-name=cc1plus` -v exist and have contents that make sense?

I don't know why that's not working...

That's great :). Though I don't see why things can't be hardcore projects and learning experiences at the same time! ;)

Re: Alternate GCC Toolchain
 

Well there's the problem. It appears to be looking for the includes in /usr/local instead of /usr. Here's the output from your line of bash.
This might be due to if finding things in /usr/local/lib that it shouldn't because of remnants of old installed-from-source toolchains. I'll try to get rid of breadcrumbs and report back.

EDIT: I think there's a bug in the wrs-headers-installer package. It doesn't actually remove a bunch of stuff, and I get a warning about the directory not being removed because its not empty. Here's the output.

Re: Alternate GCC Toolchain
 

Well, after becoming pretty sure that I've removed all the breadcrumbs from having the compiler installed under /usr/local, I tried the process again, now it can't find any of the headers due to looking for them in /usr/local. Heres the new include search paths.
EDIT: Fixed this. I had old binaries in /usr/local/bin that were causing GCC to think that it was installed there.

EDIT 2: Only problem I'm having at the moment is cpack putting wpilib in the wrong spot. I'm trying to use cpack just to learn how to before reverting back to the regular packages. cpack seems to ignore CMAKE_INSTALL_PREFIX.

Re: Alternate GCC Toolchain
 

Thank you for your work. I'll be mirroring the files at http://www.eshsrobotics.com/mirror/frctoolchain.zip

Re: Alternate GCC Toolchain
 

Thank you for your work. I'll definitely be contributing to this project.

I'm mirroring your binaries on our team website http://eshsrobotics.com/mirror/frctoolchain.zip

I'll eventually set up a PPA.

Re: Alternate GCC Toolchain
 

Hi everybody. Just as an update, I've been dorking around with using lambda functions to define delegate math inline. For an example of the usage of a lambda function on a FIRST robot, take a quick look at the Loader::Loader(Joystick *) constructor in this file:
https://github.com/rmr662/temp-test-.../RMRLoader.cpp

Please note that this will only work with C++11.

Re: Alternate GCC Toolchain
 

Has anybody gotten the gcc-4.8 source package from experimental to build for powerpc-wrs-vxworks? It should work with a custom tarball but I want to know if anybody's done it before I delve into it and write a tutorial for no reason.

I thought I would get going on it since I just recently built my toolchain for arm-linux-gnueabihf.

I've managed to get at least the binutils to build for powerpc-wrs-vxworks with just the source package straight out of wheezy. I'll do some more testing when I get home, but as far as I can tell, the only major difference is going to be that internalization is enabled.

If anybody would like to help me out, I'll attach the binary package so you can give it a shot. Keep in mind that its not signed or anything as I'm not quite sure how that works yet.

If this does work with the rest of the toolchain, then we could update the dependencies for the other packages and deprecate the use of the custom package unless there's something that I'm missing.

http://temp-share.com/show/FHKdR60U6

Re: Alternate GCC Toolchain
 

I've updated my build script to build a toolchain using a gcc snapshot and no patches to anything.

https://bitbucket.org/jmesmon/vxworks-gcc-patches

Keep in mind that this does delete quite a few directories, make sure you've read the script before using it.

Some caveats on this build and gcc in general:

• I had to disable building of gcov via "inhibit_libc=true", the fixincludes don't work around it's use of open() or mkdir().
• Setting WIND_BASE is still necessary (this is rather silly)
• I haven't run this on a real robot. The only thing I've test built is here
• I have set it to build libstdc++-v3, but I have no idea if that will work with vxworks.
• I don't do any extraneous copying or symlinking. Issues with "coreip" are expected. Fixing these need changes to "-isystem" within gcc (coincidentally the same thing that hilariously wants WIND_BASE)

Re: Alternate GCC Toolchain
 

Hi everybody! I've been trying to get this built on my Gentoo box, but I've run into issues, and googling hasn't turned up anything. It compiles a few things, then I run into this:

Then the error cascades and make exits error code 2. Unfortunately, I don't know enough about GCC to diagnose the issue. Any pointers?

Re: Alternate GCC Toolchain
 

Please Identify

• the version of gcc used
• the configure command used
• the make command used

Re: Alternate GCC Toolchain
 

The output of gcc --version is:
The configure command was:
And the make command was just
Thanks for the help!

Re: Alternate GCC Toolchain
 

Please indicate the version of the gcc source code you are building (not the version of gcc you are using to build it).

You may need to pass the location of the headers to gcc's configure command in "--with-headers" (unless you've copied them in place previously).

This isn't your current issue, but for "make" to work you'll need to do "make -j4 inhibit_libc=true" (--without-gcov doesn't appear to work, adding "inhibit_libc=true" actually prevents gcov from being built).