Alternative Toolchain
 

Hi everyone,

I'm not a huge fan of WindRiver's IDE - eclipse based IDEs are VERY slow on my machine. Plus, being on linux, I'd rather have something I can run natively (ucpp is GREAT, but it still runs the compiler through wine). The gccdist also has an ancient version of gcc.

With this in mind, I was wondering if anyone had success with compiling an alternate toolchain. I was able to compile gcc/g++ to target vxworks, but libstdc++ failed at configure.

Also, if anyone has gotten gdb to attach to a FRC robot outside of WRWB, I'd love to hear how you did it.

Re: Alternative Toolchain
 

What errors did you get in libc configure ?

What did your configure line look like ?

Re: Alternative Toolchain
 

I got some new patches and it compiles successfully now.

Im worried about the licensing implications of static linking with libstdc++. But i guess it will wotk: i just have to change my ISC license statement to a GPL license. If I change libstdc++ to dynamically link, can I add it to ni-rt.ini?

Gdb is the next big component to compile and get working. Anyone know what windriver does with gdb under the hood?

Ill take a look at ucpp's makefile generator and try and get everythimg to work together for a full native build.

Re: Alternative Toolchain
 

I compiled gdb but it seems to lack remote vxWorks debugging support (even though its --target is powerpc-wrs-vxworks). Looking through the mailing list archives I couldn't find a difinitive answer but I can guess that remote support was removed from gdb after WindRiver changed the debugging protocol they used.

I suppose I can get a copy of the source from WindRiver, as (I believe) their debugger is based on GDB and is thus GPL'd. I know there's something called tgtsvr though and I don't know what that does and what the license terms are for that program. I also don't know if it is a necessary component of the debugging toolchain or if it is only there in case one needs added features.

Re: Alternative Toolchain
 

FYI there is also a bunch of information (including links to pre-built gcc toolchain) available in this article on the NI website.

- Ron
Team #2607 controls mentor

Re: Alternative Toolchain
 

I know of their binary distribution, but 1) it's ancient (gcc 3.4!?) and 2) it is a windows binary.

I think I'll ask WindRiver for their sources to vxgdb. Since it's a fork of gdb (AFAIK) they have to give sources on request. That still doesn't give me tgtsvr (which is probably proprietary), but it might at least give me the target vxworks directive.

Re: Alternative Toolchain
 

Any details on how you achieved this stuff? I need to write some code this weekend and my windows box just took a dive, might be looking into doing some dev work on either a linux vm or os x.

Re: Alternative Toolchain
 

@Andrew: The stable and default choice for compiling FRC applications without WindRiver is the ucpp project: https://github.com/nikitakit/ucpp

ucpp works fine for most people. However, it uses the "gccdist" toolchain provided by NI internally to do all of its compilation. This gccdist has a few shortcomings. For one, it is a windows binary. ucpp gets around this by running the compiler through wine (which works fine). It's trivial to get running on linux, but it's relatively slow (I know wine on OSX is a bit of a pain in the butt, so your mileage may vary). A second is that it is based off of gcc 3.4.4. Newer versions of gcc are faster, have better optimizations, and (most importantly) have support for the new C++11 standard. A bunch of people are working on compiling their own gcc and libstdc++ in order to take advantage of this new funcitonality and have a native build. Build scripts for that can be found here: https://bitbucket.org/jmesmon/vxwork...tches/overview

I would recommend getting ucpp working on your system first (reliability trumps all). If you'd like to help with building a new toolchain, that would be awesome as well. It is very much a work in progress. I don't think anyone has tested building on a Mac either.

Re: Alternative Toolchain
 

OK, so a quick question:

The makefile generated by WindRiver has -mno-implicit-fp. On my gcc this fails; the option is unrecognized.

I was wondering why this option is there, and if -msoft-float can be used as a replacement.