Go to Post Andymark has everything! - nighterfighter [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rating: Thread Rating: 6 votes, 5.00 average. Display Modes
  #16   Spotlight this post!  
Unread 05-11-2012, 12:14
agartner01 agartner01 is offline
Captain + Control Sys & Design
FRC #4174
Team Role: Engineer
 
Join Date: Feb 2012
Rookie Year: 2012
Location: Hector MN
Posts: 109
agartner01 is an unknown quantity at this point
Re: Alternate GCC Toolchain

Alright! After a few more symlinks, cmake and make ran without incident. Build of wpilib succeeded. I'll test it on our robot tomorrow and see if it works. Thanks for all the hard work!
  #17   Spotlight this post!  
Unread 05-11-2012, 21:48
agartner01 agartner01 is offline
Captain + Control Sys & Design
FRC #4174
Team Role: Engineer
 
Join Date: Feb 2012
Rookie Year: 2012
Location: Hector MN
Posts: 109
agartner01 is an unknown quantity at this point
Re: Alternate GCC Toolchain

Robot code build completes but gives this error:
Code:
alex@alex-U46SV:~/robot$ make
[100%] Built target FRC_UserProgram
alex@alex-U46SV:~/robot$ make clean
alex@alex-U46SV:~/robot$ make
[100%] Building CXX object CMakeFiles/FRC_UserProgram.dir/src/MyRobot.cpp.obj
Linking CXX executable bin/FRC_UserProgram.out
powerpc-wrs-vxworks-nm: '/usr/local/lib/gcc/powerpc-wrs-vxworks/4.7.2/libgcc.a': No such file
[100%] Built target FRC_UserProgram
When I deploy, I get nothing but "relocation value does not fit in 24 bits"
  #18   Spotlight this post!  
Unread 05-11-2012, 23:02
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

That's probably due to the toolchain expecting a different version in GCC. Try and symlink /usr/local/lib/gcc/powerpc-wrs-vxworks/4.7.2 to 4.8.0 to get rid of the version conflict for now. Hopefully this fixes your "24 byte" issue. If that doesn't work, I'd double check to make sure that the link script is functioning properly.

Sorry it's been untested, but I literally posted this as soon as I got word that the patches had made it in. I was excited...

Also, past compile time I can't help you unless someone happened to send me a cRIO There's several other good people on the forums who can help though. And google.

I also deployed code with a hacked gcc 4.7.1 last year and it worked flawlessly, so it *is* possible to get this working...
  #19   Spotlight this post!  
Unread 06-11-2012, 14:02
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
Re: Alternate GCC Toolchain

I'll be testing this on the cRIO as soon as possible. Also, now that rbmj has pulled in my changes to the cmake toolchain, the symlinks should no longer be necessary. At least with the hacked version of 4.7.2, I was able to compile with no symlinks or anything. I didn't get the libgcc error either.
  #20   Spotlight this post!  
Unread 06-11-2012, 14:08
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
Re: Alternate GCC Toolchain

Quote:
Originally Posted by agartner01 View Post
Robot code build completes but gives this error:
Code:
alex@alex-U46SV:~/robot$ make
[100%] Built target FRC_UserProgram
alex@alex-U46SV:~/robot$ make clean
alex@alex-U46SV:~/robot$ make
[100%] Building CXX object CMakeFiles/FRC_UserProgram.dir/src/MyRobot.cpp.obj
Linking CXX executable bin/FRC_UserProgram.out
powerpc-wrs-vxworks-nm: '/usr/local/lib/gcc/powerpc-wrs-vxworks/4.7.2/libgcc.a': No such file
[100%] Built target FRC_UserProgram
When I deploy, I get nothing but "relocation value does not fit in 24 bits"
Ok after looking over your post again, I found the issue. You've installed gcc with the prefix `/usr`, whereas the toolchain file for cmake is expecting you to have installed to /usr/local. Personally, I would reinstall gcc to /usr/local because that's where you're supposed to put things that you've installed from source, but you could also fix the problem by making the following edits to the `vxworks_toolchain.cmake` file.

Code:
-set(TOOLCHAIN_PREFIX "/usr/local/powerpc-wrs-vxworks")
+set(TOOLCHAIN_PREFIX "/usr/powerpc-wrs-vxworks")
Code:
-set(VXWORKS_LIBGCC "/usr/local/lib/gcc/powerpc-wrs-vxworks/${GCC_VERSION}/libgcc.a")
+set(VXWORKS_LIBGCC "${TOOLCHAIN_PREFIX}/../${GCC_VERSION}/libgcc.a")
At least from what I've read of your problem, that should do the trick.
  #21   Spotlight this post!  
Unread 12-11-2012, 22:56
agartner01 agartner01 is offline
Captain + Control Sys & Design
FRC #4174
Team Role: Engineer
 
Join Date: Feb 2012
Rookie Year: 2012
Location: Hector MN
Posts: 109
agartner01 is an unknown quantity at this point
Re: Alternate GCC Toolchain

Quote:
Originally Posted by CodeYeti View Post
Ok after looking over your post again, I found the issue. You've installed gcc with the prefix `/usr`, whereas the toolchain file for cmake is expecting you to have installed to /usr/local. Personally, I would reinstall gcc to /usr/local because that's where you're supposed to put things that you've installed from source, but you could also fix the problem by making the following edits to the `vxworks_toolchain.cmake` file.

Code:
-set(TOOLCHAIN_PREFIX "/usr/local/powerpc-wrs-vxworks")
+set(TOOLCHAIN_PREFIX "/usr/powerpc-wrs-vxworks")
Code:
-set(VXWORKS_LIBGCC "/usr/local/lib/gcc/powerpc-wrs-vxworks/${GCC_VERSION}/libgcc.a")
+set(VXWORKS_LIBGCC "${TOOLCHAIN_PREFIX}/../${GCC_VERSION}/libgcc.a")
At least from what I've read of your problem, that should do the trick.
Alright, I tried rebuilding it with '--prefix=/usr/local' however, I encountered errors during the build process.
Code:
In file included from /usr/powerpc-wrs-vxworks/wind_base/target/h/vxWorksCommon.h:200:0,
                 from /usr/powerpc-wrs-vxworks/wind_base/target/h/vxWorks.h:84,
                 from /usr/powerpc-wrs-vxworks/wind_base/target/h/private/handleLibP.h:21,
                 from /usr/powerpc-wrs-vxworks/wind_base/target/h/stdio.h:62,
                 from ../../../gcc-master/libgcc/../gcc/tsystem.h:88,
                 from ../../../gcc-master/libgcc/libgcov.c:29:
/usr/powerpc-wrs-vxworks/wind_base/target/h/types/vxTypesOld.h:160:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
 typedef int   (*FUNCPTR) ();    /* ptr to function returning int */
 ^
/usr/powerpc-wrs-vxworks/wind_base/target/h/types/vxTypesOld.h:169:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
 typedef void   (*VOIDFUNCPTR) (); /* ptr to function returning void */
 ^
/usr/powerpc-wrs-vxworks/wind_base/target/h/types/vxTypesOld.h:178:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
 typedef double   (*DBLFUNCPTR) ();  /* ptr to function returning double*/
 ^
/usr/powerpc-wrs-vxworks/wind_base/target/h/types/vxTypesOld.h:187:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
 typedef float   (*FLTFUNCPTR) ();  /* ptr to function returning float */
 ^
../../../gcc-master/libgcc/libgcov.c: In function '__gcov_execl':
../../../gcc-master/libgcc/libgcov.c:1208:3: warning: implicit declaration of function 'execv' [-Wimplicit-function-declaration]
   return execv (path, args);
   ^
make[2]: Leaving directory `/home/alex/gcc-items/gcc-build/powerpc-wrs-vxworks/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/alex/gcc-items/gcc-build'
make: *** [all] Error 2
Also, now when I install to /usr I have to copy the powerpc* files from /usr/bin to /usr/bin/local. After that, I get this:
Code:
/usr/powerpc-wrs-vxworks/sys-include/types/vxTypesBase.h:53:20: fatal error: stddef.h: No such file or directory
 #include <stddef.h>
It looks like I'd have to include this dir with cmake, but I have no idea how to do so...
Code:
/usr/lib/gcc/powerpc-wrs-vxworks/4.8.0/include
Also, the one edit you wanted me to make to the toolchain file didn't make sense:
Quote:
Originally Posted by CodeYeti View Post
Code:
-set(VXWORKS_LIBGCC "/usr/local/lib/gcc/powerpc-wrs-vxworks/${GCC_VERSION}/libgcc.a")
+set(VXWORKS_LIBGCC "${TOOLCHAIN_PREFIX}/../${GCC_VERSION}/libgcc.a")
I found it at:
Code:
set(VXWORKS_LIBGCC "${TOOLCHAIN_PREFIX}/../lib/gcc/powerpc-wrs-vxworks/${GCC_VERSION}/libgcc.a")
I'd really like to get this working, but it seems like I can't catch a break. Could someone remote desktop (or something like that) in and help me out? It's probably something stupid I'm overlooking...

Last edited by agartner01 : 13-11-2012 at 00:37.
  #22   Spotlight this post!  
Unread 13-11-2012, 00:45
AustinSchuh AustinSchuh is offline
Registered User
FRC #0971 (Spartan Robotics) #254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Feb 2005
Rookie Year: 1999
Location: Los Altos, CA
Posts: 803
AustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond repute
Re: Alternate GCC Toolchain

Quote:
Originally Posted by ebarker View Post
What I'm curious in learning is why so much embedded C still uses the 3.4.4 version, not the 4.xx series of gcc. That said, what are the risks of using 4.x versus 3.4.4 in an embedded system.
My understanding is that this is because the version of vxworks that we are using is ancient, and WindRiver has essentially dropped support for it. It does what NI needs for Labview, so there is no reason for NI to upgrade.

971 has been running a modern version of GCC for a while now, and has seen no issues that can be traced back to the compiler. We have been using 4.5.2 for a while, but are in the process of upgrading.
  #23   Spotlight this post!  
Unread 13-11-2012, 08:43
ebarker's Avatar
ebarker ebarker is offline
Registered User
AKA: Ed Barker
FRC #1311 (Kell Robotics)
Team Role: Mentor
 
Join Date: Jan 2006
Rookie Year: 2006
Location: Kennesaw GA
Posts: 1,437
ebarker has a reputation beyond reputeebarker has a reputation beyond reputeebarker has a reputation beyond reputeebarker has a reputation beyond reputeebarker has a reputation beyond reputeebarker has a reputation beyond reputeebarker has a reputation beyond reputeebarker has a reputation beyond reputeebarker has a reputation beyond reputeebarker has a reputation beyond reputeebarker has a reputation beyond repute
Re: Alternate GCC Toolchain

I've seen a lot of 3.4.4 work done with non FIRST, non-NI, non-vxworks, environments, hence the question about how a lot of people still use it.

That is why I was asking.
__________________
Ed Barker
  #24   Spotlight this post!  
Unread 13-11-2012, 11:41
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

Quote:
Originally Posted by CodeYeti View Post
Ok after looking over your post again, I found the issue. You've installed gcc with the prefix `/usr`, whereas the toolchain file for cmake is expecting you to have installed to /usr/local. Personally, I would reinstall gcc to /usr/local because that's where you're supposed to put things that you've installed from source, but you could also fix the problem by making the following edits to the `vxworks_toolchain.cmake` file.
Sorry, I started doing that in order to shut up lintian when I was making the debian packages for the old binary release. I'll be synchronize things when I get around to making an actual release.
  #25   Spotlight this post!  
Unread 08-01-2013, 17:42
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
Re: Alternate GCC Toolchain

Hey there it's me again! I just noticed something that may be odd, but keep in mind that the concept of "stripping" syms is new to me outside of this problem. I'm going to try some simple testing of code on our new hardware tonight, and I wanted to make sure that my binary was compiling for the correct architecture and whatnot. A `file bin/FRC_UserProgram.out' yielded the following output.
Code:
bin/FRC_UserProgram.out: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (SYSV), not stripped
I noticed that it says it's "not stripped". Does that mean that maybe when I try this on hardware I will get conflicts with the kernel? Is my stripping still not working?

Thanks in advance for the help.
  #26   Spotlight this post!  
Unread 08-01-2013, 19:47
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

Quote:
Originally Posted by CodeYeti View Post
Hey there it's me again! I just noticed something that may be odd, but keep in mind that the concept of "stripping" syms is new to me outside of this problem. I'm going to try some simple testing of code on our new hardware tonight, and I wanted to make sure that my binary was compiling for the correct architecture and whatnot. A `file bin/FRC_UserProgram.out' yielded the following output.
Code:
bin/FRC_UserProgram.out: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (SYSV), not stripped
I noticed that it says it's "not stripped". Does that mean that maybe when I try this on hardware I will get conflicts with the kernel? Is my stripping still not working?

Thanks in advance for the help.
Though stripping the symbols was my original idea, I decided to instead localize the symbols. That way the symbols would still be internally visible in case we ever get a debugger to actually *work*, but they would not conflict with the external symbols for the kernel's libgcc/stdc++/supc++. So the file is correct, it is not stripped. If you look at the stripsyms script what it does is loads the symbols from these libraries into a file and then has objdump look for instances of those symbols in the executable and localize them. I figured this was as close as optimal to an ideal solution.

ALSO, w/r/t why 3.4?

Basically newer versions of GCC have issues on windows where it is very difficult to get any sort of cross compiler set up. I think MinGW doesn't support any cross compiler >3.4.5. So by moving to linux (it might also be an interesting experiment to try this toolchain in cygwin) you also gain the ability to tap the last 10 years of innovation from the GNU project
  #27   Spotlight this post!  
Unread 10-01-2013, 16:17
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

I have some beta-quality binaries up and running! These aren't the crappy binaries from the last toolchain but real, full debian toolchain binary packages. As always, all of the source is on my GitHub page. Sorry, but these are based off of debian (testing, specifically), and I don't have time to package every distro out there. They should work on *buntu and mint though (somebody confirm?). Feel free to try installing via alien on rpm or tgz based systems, but your mileage may vary.

Also, if any debian developers happen to read this, these packages make lintian want to barf. However they work and I've removed any really serious violations.

Though GitHub doesn' t offer downloads anymore, I was able to upload the files to dropbox (google drive didn't like the large files). Link:

https://www.dropbox.com/sh/0odxo8r92reos4z/1wIQYNwpaW

Note (if you are unfamiliar with these things) that unless you are going to try and compile from source you don't need the .dsc files. Those go with the original source code (which you can find if you look for it, a lot of it is on my github page, but NOT gcc or binutils - grab the right version of binutils from GNU and the current development branch of gcc).


As a request, is anyone willing to mirror the debs and/or provide a repo so that people can add it to the /etc/apt/sources.list? That would be awesome

Setup:

install the wrs-headers-installer package, then the powerpc-wrs-vxworks- packages (binutils, gcc, buildscripts, in that order), then the wpilib package. After that, you have a working toolchain! You'll also want cmake if you don't have that already.

Again, I don't have a repo, so dependency handling is a pain in the rear.

New workflow:

Add a CMakeLists.txt file to your code. This suffices as a minimal example:
Code:
cmake_minimum_required(VERSION 2.8)
include(FRCDeploy)

project(robot_code)
find_package(WPILib)

file(GLOB_RECURSE SOURCE_CODE *.cpp)

include_directories(${WPILib_INCLUDE_DIRS})
add_executable(robot_module ${SOURCE_CODE})
target_link_libraries(robot_module ${WPILib_LIBRARY})
add_make_deploy(robot_module 10.xx.yy.2)
Then, go to your build directory (I will assume they are called sourcedir and builddir and are in the same directory) and do the following:

Code:
$ mkdir ../builddir
$ cd ../builddir
$ frcmake ../sourcedir
NOTE THAT ITS FRCMAKE, *NOT* CMAKE.

frcmake is a wrapper for cmake that adds on some command line arguments to make your life easier...

Then, all you need is:
Code:
$ make
$ make deploy
Cross your fingers, and it should work!

Now, a disclaimer: I have not tested code built using this compiler. Since beginning this project I have gone off to college and now no longer have access to shiny cRIOs . PLEASE PLEASE PLEASE somebody test things out! I know that when I left school the toolchain worked with few issues. I've been able to fix many issues and can confirm that this builds REAL ROBOT CODE with WPILib successfully. However I can no longer say with certainty if such code will run correctly. IF it doesn't work, please tell me! However, know that I cannot help you without NETCONSOLE OUTPUT. Even then, sometimes it's cryptic and I hope that there are brave souls (CodeYeti, are you out there? ) that can work with you and squash any bugs. I'm hoping that this is early enough in the build season that people still have time to play with things

Note: As a minor bug if you want to use the 'make deploy' functionality you need to have wput installed on your system, which isn't a dependency of the package. This is because I plan to remove the dependency in the future, I'm lazy, and I've already invoked debuild a few too many times for my own sanity this week :/
  #28   Spotlight this post!  
Unread 10-01-2013, 19:04
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

Forgot - these packages are signed with my public key. It's attached.
Attached Files
File Type: txt pubkey.txt (1.7 KB, 4 views)
  #29   Spotlight this post!  
Unread 10-01-2013, 21:55
danopia's Avatar
danopia danopia is offline
Logical Awesome
AKA: Daniel Lamando
no team
 
Join Date: Dec 2011
Rookie Year: 2012
Location: Philadelphia, PA
Posts: 24
danopia is an unknown quantity at this point
Send a message via AIM to danopia Send a message via MSN to danopia Send a message via Yahoo to danopia
Re: Alternate GCC Toolchain

I have a high-bandwidth web server that can host any arbitrary files, if you tell me how to set up a repo I can do that for you. (I assume that mirroring just the binaries alone is not enough?)
  #30   Spotlight this post!  
Unread 11-01-2013, 11:30
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

Quote:
Originally Posted by danopia View Post
I have a high-bandwidth web server that can host any arbitrary files, if you tell me how to set up a repo I can do that for you. (I assume that mirroring just the binaries alone is not enough?)
Unfortunately it is quite a bit more involved. It requires installing some specialized programs on the computer in question to generate the description files

Mirroring the files would be awesome though

I would host the repo myself except I'm no longer at home to keep my parents from shutting down my server (something about a waste of electricity...). So, although my system has all the software, I can't access it.

Perhaps it might be possible to set up a repo in a virtual machine and then once that is working rsync all of the files up to the server (as the files are served over http, so you don't actually need to add any services). I don't know if anyone has done that before or gotten it to work.

I also just checked the md5sums to verify the upload worked (it did). Hopefully these should install correctly.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 13:54.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


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