Chief Delphi

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)

codes02 18-02-2013 19:23

Re: Alternate GCC Toolchain
 
Quote:

Originally Posted by rbmj (Post 1235865)
GCC wants <header dir>/wrn/coreip in the search path. The way this is solved is by putting the headers in /usr/powerpc-wrs-vxworks/sys-include and then symlinking /usr/powerpc-wrs-vxworks/include to sys-include/wrn/coreip

I am almost certain this is not correct. I've built gcc fine without any symlinking mess. I suspect MaraschinoPanda's problem has a different solution (though by all means, try this one).

rbmj 18-02-2013 20:19

Re: Alternate GCC Toolchain
 
Quote:

Originally Posted by codes02 (Post 1235875)
I am almost certain this is not correct. I've built gcc fine without any symlinking mess. I suspect MaraschinoPanda's problem has a different solution (though by all means, try this one).

It is correct.

GCC wants to see wrn/coreip. There are many ways you can do this. You don't need to symlink. But it's easier. There are other hacks around it, but that's the simplest way, and it works nicest with fixincludes.

codes02 18-02-2013 20:43

Re: Alternate GCC Toolchain
 
limits.h is in target/h, not target/h/wrn/coreip , so symlinking in wrn/coreip will not help at all for this error.

rbmj 18-02-2013 20:52

Re: Alternate GCC Toolchain
 
Quote:

Originally Posted by codes02 (Post 1235914)
limits.h is in target/h, not target/h/wrn/coreip , so symlinking in wrn/coreip will not help at all for this error.

I was referring to:
Quote:

Code:

/home/maraschinopanda/alt-gcc/gcc-build/gcc/include-fixed/ioLib.h:148:21: fatal error: net/uio.h: No such file or directory
#include <net/uio.h>



wlmeng11 19-02-2013 00:07

Re: Alternate GCC Toolchain
 
Hi!
I built this successfully on Arch Linux x64 with the instruction in the OP save for the unzip command having the wrong name (should be "unzip master.zip" ) and building gcc-build with "make -j4 inhibit_libc=true".

I haven't tested on a robot yet, but successfully compiled jmesmon's test program.
https://github.com/jmesmon/frc-min

I will try to make a PKGBUILD for this in the Arch Linux AUR if I can.

byteit101 19-02-2013 11:57

Re: Alternate GCC Toolchain
 
I've successfully compiled GCC and friends, and can use frcmake to compile robot code successfully. However, I can't seem to figure out how to compile another project that uses autotools (./configure), it always fails on trying to find pthreads, with the last screenfull saying "checking for pthread_***... no" and ending with 'configure: WARNING: "Don't know how to find pthread library on your system -- thread support disabled"'

I can however compile using frcmake pthread stuff, so I think its just a matter of a missing path/configuration

here is my current command:
Code:

LDFLAGS=-L/usr/powerpc-wrs-vxworks/lib/ CFLAGS='-I/usr/powerpc-wrs-vxworks/include/:/usr/powerpc-wrs-vxworks/sys-include/ -mcpu=603 -mstrict-align -mlongcall -nostdlib -ansi -Wall  -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL' PATH=/usr/powerpc-wrs-vxworks/bin:$PATH ./configure --host=powerpc-wrs-vxworks
I've never done anything more than basic cross compiling before, so i'm rather lost...


UPDATE: I figured it out. configure was resetting my LIBS for several things, '-lm' for math, and '-lpthread' for pthreads. Is there a way to have it ignore these libraries since they seem to be built in?

codes02 19-02-2013 20:50

Re: Alternate GCC Toolchain
 
frcmake link for those (like me) who end up googling around.

Don't add the -L to LDFLAGS and that -I to CFLAGS : those are the defaults which the compiler will already use.

The other CFLAGS _may_ be needed. Specifically the -m* options are probably needed, the -D* options depend on how funky vxworks' headers are, and the others could be omitted based on preference. I don't _think_ '-nostdlib' is needed, though I might be wrong on that.

I tend to set PATH globally (in bashrc or otherwise), but setting it there is valid. Actually, instead of setting path, passing --prefix=/usr/powerpc-wrs-vxworks (in your case) probably makes more sense.

Essentially, I'd try the following and then tweak it when it doesn't work because someone screwed up their build system.
Code:

CFLAGS='-mcpu=603 -mstrict-align -mlongcall -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL' ./configure --host=powerpc-wrs-vxworks --prefix=/usr/powerpc-wrs-vxworks
(this all comes with the caveat that I've never built code that ran on a cRIO).

Edit: Digging a bit more, _WRS_KERNEL_, TOOL_FAMILY, and CPU are defined properly without the need for -D*.
(CPU is PPC604 unless -mcpu=603 is passed, which is strange given the --with-cpu-PPC603 configure option was used)

Potentially bringing it down to:
Code:

CFLAGS='-mcpu=603 -mstrict-align -mlongcall -DTOOL=gnu' ./configure --host=powerpc-wrs-vxworks --prefix=/usr/powerpc-wrs-vxworks

byteit101 21-02-2013 18:38

Re: Alternate GCC Toolchain
 
I must say, this is very cool. Has anyone gotten GDB or any debugging working yet?

rbmj 21-02-2013 20:34

Re: Alternate GCC Toolchain
 
Quote:

Originally Posted by byteit101 (Post 1236322)
I've successfully compiled GCC and friends, and can use frcmake to compile robot code successfully. However, I can't seem to figure out how to compile another project that uses autotools (./configure), it always fails on trying to find pthreads, with the last screenfull saying "checking for pthread_***... no" and ending with 'configure: WARNING: "Don't know how to find pthread library on your system -- thread support disabled"'

I can however compile using frcmake pthread stuff, so I think its just a matter of a missing path/configuration

here is my current command:
Code:

LDFLAGS=-L/usr/powerpc-wrs-vxworks/lib/ CFLAGS='-I/usr/powerpc-wrs-vxworks/include/:/usr/powerpc-wrs-vxworks/sys-include/ -mcpu=603 -mstrict-align -mlongcall -nostdlib -ansi -Wall  -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL' PATH=/usr/powerpc-wrs-vxworks/bin:$PATH ./configure --host=powerpc-wrs-vxworks
I've never done anything more than basic cross compiling before, so i'm rather lost...


UPDATE: I figured it out. configure was resetting my LIBS for several things, '-lm' for math, and '-lpthread' for pthreads. Is there a way to have it ignore these libraries since they seem to be built in?

I'm glad you figured it out. Just a warning though - when you try and put that on a robot it might fail, reason being that the link process that frcmake uses (and hides from you) is relatively strange.

Here's an explanation of what the cmake-based buildchain does to link your robot code module:

1) links as normal, without any libraries
2) statically links in the standard library
3) runs a script called "munch"
4) links the output of (2) with the output of (3)
5) runs a script called stripsyms

Note: The default build toolchain does (1) and (3) and then links them together

An explanation for munch: this finds all of the constructors and destructors of global or static objects in the binary and creates a special vxworks data structure that will allow vxworks to run these.

Also, with the new toolchain, we link the necessary standard libraries statically. In the default implementation, the standard libraries is linked dynamically, and vxworks already loads a copy of the standard library into memory, so your code sees these symbols and works. However, because of any incompatibilities between the old and new versions at a binary level, we include our own copy. This is where stripsyms comes in

Stripsyms is necessary in order to localize (think hide) our copy of the vxworks standard library from the rest of the system. This way, when vxworks loads our code, it doesn't load the symbols from our copy of the standard library into memory, so the rest of the OS can pretend that our copy doesn't exist.

This manual linking and processing is the reason why '-nostdlib' is necessary - don't want to prematurely link in something twice. It's not the most elegant way to do things, but it's the way that worked for me. At the end of the 2012 season I spent quite a bit of time fiddling with this, and it took a *long* time before I could finally get everything to cooperate and run successfully.

Thus, any third-party code might require some special coaxing before it'll work on a real robot :(

Also, I am relying on the community to test this project. It still hasn't been vigorously tested in a production environment using all the features and possible corner cases. Right now I am not a good maintainer as my time is severely limited and I do not have access to a cRIO to run code on :(

I'm hoping that with a bit of testing, once GCC 4.8 is released this can be sufficiently mature to offer to teams as a stable alternative to the official toolchains and the UCPP project (a great project, but with different aims) for real robot code (not just to play with). Though, if anyone *is* using this on their robot, I'm eager to hear how it turns out!

Also, as a bit of good news, my final patch for GCC got accepted (though for 4.8.1, not 4.8.0 :/). There's still no real support for any other languages (fortran is the closest I think, but when I tried to make it gcc's build system acts strangely). Don't worry though, that patch relates to a corner case in thread specific data, so for 99% of people 4.8.0 should be safe.

Quote:

I must say, this is very cool. Has anyone gotten GDB or any debugging working yet?
I'm glad you think it's cool too :)

No, I haven't gotten GDB working. There's a couple of different ways to attack the issue, and I'm not sure what's best.

codes02 22-02-2013 21:38

Re: Alternate GCC Toolchain
 
Can you link to the patch that is going into 4.8.1?

rbmj 23-02-2013 00:33

Re: Alternate GCC Toolchain
 
It's uber trivial (has to do with neglecting to pass an argument to a function, that's it), but here you go: http://article.gmane.org/gmane.comp.gcc.patches/281127/

William Kunkel 23-02-2013 21:03

Re: Alternate GCC Toolchain
 
Alright, I got it to compile, but I think I might have issues. The cmake scripts depend on "/usr/powerpc-wrs-vxworks/lib/libstdc++.a" and "/usr/powerpc-wrs-vxworks/lib/libsupc++.a" existing, but post-install, they are nowhere to be found. Did I miss a step? Or are they added by the debian package that I cannot use?

codes02 24-02-2013 05:51

Re: Alternate GCC Toolchain
 
So, it turns out I (or we) haven't actually been building with libstdc++-v3 enabled, because the flag is "--enable-libstdcxx" not "--enable-libstdc++-v3". As I'm pretty sure it was being built with 4.7.x, my guess is that the flag got changed in 4.8.

In short, this is my current gcc configure (I've also fiddled with static & shared, you could leave those as they were previously set if there are issues in practice):
Code:

        FLAGS_FOR_TARGET="-isystem $PREFIX/powerpc-wrs-vxworks/sys-include/wrn/coreip"

        CFLAGS_FOR_TARGET="$FLAGS_FOR_TARGET"\
        CXXFLAGS_FOR_TARGET="$FLAGS_FOR_TARGET" \
        "$SRC/gcc-$GCC_VERSION/configure" \
            --prefix="$PREFIX" \
            --target=powerpc-wrs-vxworks \
            --with-gnu-as \
            --with-gnu-ld \
            --with-headers="$WIND_BASE/target/h" \
            --disable-libssp \
            --disable-multilib \
            --with-float=hard \
            --enable-languages=c,c++ \
            --enable-threads=vxworks \
            --enable-libstdcxx \
            --without-gconv \
            --disable-libgomp \
            --disable-nls \
            --disable-libmudflap \
            --with-cpu-PPC603 \
            --enable-static \
            --enable-shared


William Kunkel 24-02-2013 14:23

Re: Alternate GCC Toolchain
 
I finally figured out what was wrong with the symlinking! In the second step, we make the directory "/usr/powerpc-wrs-vxworks/include". So, when we try to make a symlink with the same name later:
Code:

ln -s sys-include/wrn/coreip /usr/powerpc-wrs-vxworks/include
It instead is placed inside that directory as a symlink called "coreip" which is now referencing an invalid location. If that directory is never created, then everything builds as expected.

William Kunkel 24-02-2013 15:18

Re: Alternate GCC Toolchain
 
Does anyone have an example of a CMakeLists.txt file for a robot project? I'm a little lost on what to do, and being able to see one would help greatly.

rbmj 24-02-2013 16:22

Re: Alternate GCC Toolchain
 
With my setup, I have:
Code:

cmake_minimum_required(VERSION 2.8)

include(FRCDeploy)

project(GUILLOTINE)

file(GLOB_RECURSE SOURCE_CODE *.cpp)

find_package(WPILib)

include_directories(${WPILIB_INCLUDE_DIRS})

add_executable(612-code ${SOURCE_CODE})

target_link_libraries(612-code ${WPILIB_LIBRARY})

add_make_deploy(612-code 10.6.12.2)

Let me know if a similar setup causes any issues for you, and if it will run on real hardware. If it doesn't, please supply a build log using make VERBOSE=1 (remember to make clean first), your CMakeLists.txt file, and a log of netconsole output (if applicable).

William Kunkel 24-02-2013 18:36

Re: Alternate GCC Toolchain
 
Thanks for the help!

William Kunkel 24-02-2013 20:51

Re: Alternate GCC Toolchain
 
Alright, one final thing. I seem to be missing "/usr/powerpc-wrs-vxworks/share/ldscripts/dkm.ld". Where is this supposed to come from? I didn't see it in any of the git repos and it didn't look like it was generated by any of the CMakeLists files. I'm probably missing something obvious.

rbmj 25-02-2013 19:03

Re: Alternate GCC Toolchain
 
It's generated by my wrs-headers-installer install script. You can see it near the bottom of that script. Link: https://github.com/rbmj/wrs-headers-...ebian/postinst

wlmeng11 28-02-2013 00:31

Re: Alternate GCC Toolchain
 
Has anyone been able to build this with Ubuntu 12.04? (x86_64)
I was able to build it fine on both of my Arch Linux machines, but no luck on Ubuntu.
Here is one of the errors while compiling gcc-build (with "make -j4 inhibit_libc=true"):
Quote:

g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -W c
ast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE
-I. -Ibuild -I../../gcc-master/gcc -I../../gcc-master/gcc/build -I../../gcc-master/gcc/../include -I../../gcc-master/gcc/../libcpp/include -I../../gcc -
master/gcc/../libdecnumber -I../../gcc-master/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-master/gcc/../libbacktrace \
-DBASEVER="\"4.8.0\"" -DDATESTAMP="\" 20130227\"" \
-DREVISION="\"\"" \
-DDEVPHASE="\" (experimental)\"" -DPKGVERSION="\"(GCC) \"" \
-DBUGURL="\"<http://gcc.gnu.org/bugs.html>\"" -o build/version.o ../../gcc-master/gcc/version.c
/usr/powerpc-wrs-vxworks/bin/as: unrecognized option '--64'
make[2]: *** [build/version.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/bin/bash ../../gcc-master/gcc/../move-if-change tmp-optionlist optionlist
echo timestamp > s-options
make[2]: *** wait: No child processes. Stop.
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/wmeng/vxworks-gcc/gcc-build'
make: *** [all] Error 2

William Kunkel 01-03-2013 14:27

Re: Alternate GCC Toolchain
 
Does anyone know if there's support for C++11's new math functions, namely copysign()? It wasn't working for me, but that could just be on my end.

rbmj 01-03-2013 19:47

Re: Alternate GCC Toolchain
 
Quote:

Originally Posted by MaraschinoPanda (Post 1242069)
Does anyone know if there's support for C++11's new math functions, namely copysign()? It wasn't working for me, but that could just be on my end.

There should be. Again, there used to be a bug with c++11 support, which should be fixed when I release the new packages and builds (hopefully very soon). If you can paste the errors you are getting and the output of make VERBOSE=1 I can see if you are affected by this bug and the resolution.

codes02 01-03-2013 22:06

Re: Alternate GCC Toolchain
 
@wlmeng11 I've just built it successfully in a Ubuntu 12.04 64.

The "--64" indicates 64 bit, and I'm pretty sure it should be running /user/powerpc-wrs-vxworks/bin/powerpc-wrs-vxworks-as not /user/powerpc-wrs-vxworks/bin/as .

Are you sure you passed --target to both binutils & gcc's configure?

rbmj 01-03-2013 23:43

Re: Alternate GCC Toolchain
 
Quote:

Originally Posted by codes02 (Post 1242189)
@wlmeng11 I've just built it successfully in a Ubuntu 12.04 64.

The "--64" indicates 64 bit, and I'm pretty sure it should be running /user/powerpc-wrs-vxworks/bin/powerpc-wrs-vxworks-as not /user/powerpc-wrs-vxworks/bin/as .

Are you sure you passed --target to both binutils & gcc's configure?

/usr/bin/powerpc-wrs-vxworks-as should be a hard link to /usr/powerpc-wrs-vxworks/bin/as

Binutils is fine - as isn't supposed to take a --64 argument AFAIK. Can you post your config.log?

wlmeng11 02-03-2013 00:07

Re: Alternate GCC Toolchain
 
Quote:

Originally Posted by codes02 (Post 1242189)
@wlmeng11 I've just built it successfully in a Ubuntu 12.04 64.

The "--64" indicates 64 bit, and I'm pretty sure it should be running /user/powerpc-wrs-vxworks/bin/powerpc-wrs-vxworks-as not /user/powerpc-wrs-vxworks/bin/as .

Are you sure you passed --target to both binutils & gcc's configure?

I'm using the commands from the first post for configure.
Which version of GCC are you using and where did you get it? (official repos, PPA, or source)

William Kunkel 02-03-2013 01:13

Re: Alternate GCC Toolchain
 
The complete output of make VERBOSE=1 is as follows:
Quote:

/usr/bin/cmake -H/home/maraschinopanda/src/422-robot-2013 -B/home/maraschinopanda/src/422-robot-2013 --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/maraschinopanda/src/422-robot-2013/CMakeFiles /home/maraschinopanda/src/422-robot-2013/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/maraschinopanda/src/422-robot-2013'
make -f CMakeFiles/bin/422-robot-2013.dir/build.make CMakeFiles/bin/422-robot-2013.dir/depend
make[2]: Entering directory `/home/maraschinopanda/src/422-robot-2013'
cd /home/maraschinopanda/src/422-robot-2013 && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/maraschinopanda/src/422-robot-2013 /home/maraschinopanda/src/422-robot-2013 /home/maraschinopanda/src/422-robot-2013 /home/maraschinopanda/src/422-robot-2013 /home/maraschinopanda/src/422-robot-2013/CMakeFiles/bin/422-robot-2013.dir/DependInfo.cmake --color=
make[2]: Leaving directory `/home/maraschinopanda/src/422-robot-2013'
make -f CMakeFiles/bin/422-robot-2013.dir/build.make CMakeFiles/bin/422-robot-2013.dir/build
make[2]: Entering directory `/home/maraschinopanda/src/422-robot-2013'
/usr/bin/cmake -E cmake_progress_report /home/maraschinopanda/src/422-robot-2013/CMakeFiles 20
[ 5%] Building CXX object CMakeFiles/bin/422-robot-2013.dir/Commands/CheesyDrive.cpp.obj
/usr/local/bin/powerpc-wrs-vxworks-g++ -c /home/maraschinopanda/src/422-robot-2013/Commands/CheesyDrive.cpp -o CMakeFiles/bin/422-robot-2013.dir/Commands/CheesyDrive.cpp.obj -isystem /usr/local/powerpc-wrs-vxworks/include/WPILib -mcpu=603 -mstrict-align -mlongcall -nostdlib -Wall -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL
/home/maraschinopanda/src/422-robot-2013/Commands/CheesyDrive.cpp: In member function 'float CheesyDrive::truncateOutOfBounds(float)':
/home/maraschinopanda/src/422-robot-2013/Commands/CheesyDrive.cpp:113:35: error: 'copysign' was not declared in this scope
newValue = copysign( 1.0, value );
^
make[2]: *** [CMakeFiles/bin/422-robot-2013.dir/Commands/CheesyDrive.cpp.obj] Error 1
make[2]: Leaving directory `/home/maraschinopanda/src/422-robot-2013'
make[1]: *** [CMakeFiles/bin/422-robot-2013.dir/all] Error 2
make[1]: Leaving directory `/home/maraschinopanda/src/422-robot-2013'
make: *** [all] Error 2
I've not been using the binaries, by the way, so fixing them won't fix my problem. (Woo Gentoo!) But it's possible we made the same mistake. My version of GCC is 4.8.0

codes02 02-03-2013 01:50

Re: Alternate GCC Toolchain
 
I've been building either the gcc-master tarballs from github (ie: latest snapshot), or using the date marked snapshots from the gcc mirrors.

ie: all source, all upstream.

rbmj 02-03-2013 12:22

Re: Alternate GCC Toolchain
 
Quote:

Originally Posted by MaraschinoPanda (Post 1242266)
The complete output of make VERBOSE=1 is as follows:


I've not been using the binaries, by the way, so fixing them won't fix my problem. (Woo Gentoo!) But it's possible we made the same mistake. My version of GCC is 4.8.0

If you go to a clean build directory and run:
Code:

$ frcmake $SRCDIR -DCMAKE_CXX_FLAGS='-std=c++11 -fpermissive'
Then it should work. The use of -fpermissive is evil, but I seem to remember it being necessary, I think with WPILib doing something that is officially deprecated in C++11...

wlmeng11 02-03-2013 15:13

Quote:

Originally Posted by codes02 (Post 1242283)
I've been building either the gcc-master tarballs from github (ie: latest snapshot), or using the date marked snapshots from the gcc mirrors.

ie: all source, all upstream.

Are you also building all the other libraries from source? (gmp, mpfr, and mpc)

codes02 02-03-2013 15:16

Re: Alternate GCC Toolchain
 
@wlmeng11

yes. See the build script I use, more info in this post back on page 7:
http://www.chiefdelphi.com/forums/sh...1&postcount=86

rbmj 04-03-2013 07:52

Re: Alternate GCC Toolchain
 
UPDATE:

I've figured out how to get the repository to work, and I'm in the free tier for amazon s3. Thus, here's the link to a new FirstForge wiki page on how to set it up:

http://firstforge.wpi.edu/sf/wiki/do.../BinaryInstall

Currently, I only have packages for debian wheezy. I don't know if they will be binary-compatible with Ubuntu. The only binary library dependencies are libc and zlib, which are both pretty good with compatibility, bu you never know...

There's also instructions on how to build the packages here:

http://firstforge.wpi.edu/sf/wiki/do.../ManualInstall

I'll be putting more instructions on how to compile manually from source (for other distributions) on that last page. Hopefully I should finish updating soon!

wlmeng11 04-03-2013 15:09

Quote:

Originally Posted by rbmj (Post 1243274)
UPDATE:

I've figured out how to get the repository to work, and I'm in the free tier for amazon s3. Thus, here's the link to a new FirstForge wiki page on how to set it up:

http://firstforge.wpi.edu/sf/wiki/do.../BinaryInstall

Currently, I only have packages for debian wheezy. I don't know if they will be binary-compatible with Ubuntu. The only binary library dependencies are libc and zlib, which are both pretty good with compatibility, bu you never know...

There's also instructions on how to build the packages here:

http://firstforge.wpi.edu/sf/wiki/do.../ManualInstall

I'll be putting more instructions on how to compile manually from source (for other distributions) on that last page. Hopefully I should finish updating soon!

Thank you!
The PPA worked for me on Ubuntu 12.04.

rbmj 05-03-2013 19:02

Re: Alternate GCC Toolchain
 
The new required C++ update to WPILib has been incorporated into the git repo of WPILib and the builds have been uploaded. Let me know if you have any issues. For anyone using the repo, a standard aptitude update && aptitude upgrade should do the trick.

As always, let me know of any issues that arise.

AlexBrinister 08-03-2013 18:08

Re: Alternate GCC Toolchain
 
I made a PKGBUILD for the 64-bit version of this toolchain. It is available on the AUR. If you have an AUR package installer (like yaourt), you can install it by simply doing:

Code:

yaourt -S vxworks-gcc-toolchain-bin
P.S: This is using binutils and GCC 4.8 snapshots from the 20th of January. I'm working on the i686 binary release and a source release

Alex Brinister

rbmj 09-03-2013 09:56

Re: Alternate GCC Toolchain
 
Quote:

Originally Posted by AlexBrinister (Post 1245275)
I made a PKGBUILD for the 64-bit version of this toolchain. It is available on the AUR. If you have an AUR package installer (like yaourt), you can install it by simply doing:

Code:

yaourt -S vxworks-gcc-toolchain-bin
P.S: This is using binutils and GCC 4.8 snapshots from the 20th of January. I'm working on the i686 binary release and a source release

Alex Brinister

Thanks! I'll update the wiki, which is finally getting semi-complete:

http://firstforge.wpi.edu/sf/go/proj..._toochain/wiki

AlexBrinister 10-03-2013 11:53

Re: Alternate GCC Toolchain
 
@MaraschinoPanda

Looks like you're not specifying -std=gnu++11 on the gcc command line

This is one of your compile lines:

Code:

/usr/local/bin/powerpc-wrs-vxworks-g++ -c /home/maraschinopanda/src/422-robot-2013/Commands/CheesyDrive.cpp -o CMakeFiles/bin/422-robot-2013.dir/Commands/CheesyDrive.cpp.obj -isystem /usr/local/powerpc-wrs-vxworks/include/WPILib -mcpu=603 -mstrict-align -mlongcall -nostdlib -Wall -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL
If you edit the frcmake shell script, you can add the following

Code:

CXX_FLAGS="'-std=gnu++11'"
and where it says exec ... , add "-DCMAKE_CXX_FLAGS=$CXX_FLAGS"

This should fix your problem.

Also, I would advise not installing in local if you're using a package manager. Install to /usr.

Alex Brinister

djdaugherty 10-03-2013 13:21

Re: Alternate GCC Toolchain
 
I'm not sure if this is the correct thread to ask this question, but my team is having issues starting a script automatically on our Odroid that is running Ubuntu. Can anyone give them some pointers?

Thank you!

AlexBrinister 10-03-2013 13:31

Re: Alternate GCC Toolchain
 
What kind of script is it? When do you want it to start?

If you want it to start on start-up, you can make a rc.local file in /etc/init.d. Then, you should do the following:

Code:

sudo ln -s /etc/init.d/rc.local /etc/rc<default runlevel number>.d/S99zlocal
That should do it.

Alex Brinister

djdaugherty 10-03-2013 13:50

Re: Alternate GCC Toolchain
 
Okay - they did that with a cron job using @reboot and the location of the pythin and the location of the script. The problem seems to be with network tables. The Odroid is coming up before the cRio and when the Odroid tries to connect with Network Tables on the cRio before it's up, the cRio never boots. They were getting around this problem earlier by adding a wait before they connect to the Network Tables, but that isn't going to work for autonomous mode. Is there a way to check Network Tables to see if they are running?

AlexBrinister 10-03-2013 14:04

Re: Alternate GCC Toolchain
 
I think you should start a new thread concerning this as your problem is not related to this thread. Also, I'm not familiar with NetworkTables. I assume you are using this for vision processing. Our team uses C++ and we also just have our own server and client running on an Intel NUC and the cRIO, respectively.

Alex Brinister

djdaugherty 10-03-2013 14:19

Re: Alternate GCC Toolchain
 
Okay - thank you. I have posted in a Networktables thread. I appreciate your help.

AlexBrinister 10-03-2013 15:12

Re: Alternate GCC Toolchain
 
@rbmj

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

Also, I use a different frcmake in my package. Mine looks like this:

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"

We can't have two version of this if we want to standardized? Should I remove mine and replace it with yours?

Alex Brinister

CodeYeti 11-03-2013 15:47

Re: Alternate GCC Toolchain
 
Quote:

Originally Posted by CodeYeti (Post 1233640)
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

Hi everyone, just wondering if anybody had bothered to give this a shot before I go at it tonight. No reason to solve problems that have already been solved.

byteit101 11-03-2013 16:28

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?

Alex Brinister

both

/usr/bin/powerpc-wrs-vxworks-gcc and /usr/powerpc-wrs-vxworks/bin/gcc are symlinked to each other

William Kunkel 12-03-2013 20:12

Re: Alternate GCC Toolchain
 
Have the issues remedied in the new mandatory update for C++ been addressed in rbmj's version of WPILib? Or were they even there to begin with?

agartner01 12-03-2013 20:26

Re: Alternate GCC Toolchain
 
Quote:

Originally Posted by MaraschinoPanda (Post 1247310)
Have the issues remedied in the new mandatory update for C++ been addressed in rbmj's version of WPILib? Or were they even there to begin with?

Yes.

Quote:

Originally Posted by rbmj (Post 1244137)
The new required C++ update to WPILib has been incorporated into the git repo of WPILib and the builds have been uploaded. Let me know if you have any issues. For anyone using the repo, a standard aptitude update && aptitude upgrade should do the trick.

As always, let me know of any issues that arise.

https://github.com/rbmj/wpilib/commi...bd2a05ca432d16
https://github.com/rbmj/wpilib/commi...f078440561da01

AlexBrinister 12-03-2013 20:41

Re: Alternate GCC Toolchain
 
I wanted to ask if we should have a specific version of GCC/binutils that we use for these builds. I'm using binutils 2.23.1 and GCC-HEAD for my builds. Should I revert to using binutils 2.22?

Alex Brinister

codes02 13-03-2013 01:47

Re: Alternate GCC Toolchain
 
Why would you choose to build an old version of binutils if a newer released version exists? (In other words, I'm in favor of 2.23.1).

AlexBrinister 13-03-2013 12:24

Re: Alternate GCC Toolchain
 
Because I'm pretty sure Ubuntu uses 2.22 as the default. Arch has been on 2.23 for a while so that's why I'm asking.

Alex Brinister

AlexBrinister 13-03-2013 23:00

Re: Alternate GCC Toolchain
 
Quote:

EDIT 2: To anybody that's thinking of dealing with WPILib, I suggest adding the following flag in CMAKE_CXX_FLAGS to filter out all the deprecated string literal warnings. There's no way that anybody is going to go through the whole library and convert it to using std::string unless that have absolutely no life.

-Wno-write-strings
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

rbmj 14-03-2013 10:44

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

AlexBrinister 14-03-2013 15:32

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

byteit101 16-03-2013 00:41

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.

rbmj 16-03-2013 07:58

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

rbmj 26-03-2013 20:40

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.

jwhite 26-03-2013 21:03

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

rbmj 26-03-2013 21:18

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.

jwhite 27-03-2013 00:13

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!

codes02 01-04-2013 01:45

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

rbmj 01-04-2013 07:58

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.

rbmj 12-04-2013 16:25

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


All times are GMT -5. The time now is 01:33.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi