![]() |
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_KERNELCode:
CXX_FLAGS="'-std=gnu++11'"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 |
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! |
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/S99zlocalAlex Brinister |
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?
|
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 |
Re: Alternate GCC Toolchain
Okay - thank you. I have posted in a Networktables thread. I appreciate your help.
|
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/bashAlex Brinister |
Re: Alternate GCC Toolchain
Quote:
|
Re: Alternate GCC Toolchain
Quote:
/usr/bin/powerpc-wrs-vxworks-gcc and /usr/powerpc-wrs-vxworks/bin/gcc are symlinked to each other |
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?
|
Re: Alternate GCC Toolchain
Quote:
Quote:
https://github.com/rbmj/wpilib/commi...f078440561da01 |
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 |
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).
|
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 |
Re: Alternate GCC Toolchain
Quote:
Going through and C++'ing WPILib sounds like something I'm going to do over the summer lol. Alex Brinster |
| 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