Chief Delphi - Alternate GCC Toolchain

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)

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!

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"

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

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.

Re: Alternate GCC Toolchain

Quote:

Originally Posted by agartner01 (Post 1192982)

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.

Re: Alternate GCC Toolchain

Quote:

Originally Posted by CodeYeti (Post 1193076)

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 (Post 1193076)

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

Re: Alternate GCC Toolchain

Quote:

Originally Posted by ebarker (Post 1192839)

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.

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.

Re: Alternate GCC Toolchain

Quote:

Originally Posted by CodeYeti (Post 1193076)

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.

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.

Re: Alternate GCC Toolchain

Quote:

Originally Posted by CodeYeti (Post 1210908)

Code:

bin/FRC_UserProgram.out: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (SYSV), not stripped

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 :D

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? :D) 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 :/

Re: Alternate GCC Toolchain

Forgot - these packages are signed with my public key. It's attached.

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

Re: Alternate GCC Toolchain

Quote:

Originally Posted by danopia (Post 1212703)

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.