View Full Version : Alternate GCC Toolchain
Hi all,
Just an update as everyone starts thinking about the 2013 FRC season, the patches that I and several others wrote have now been officially integrated into the GCC mainline.
Now, having undergone the sad ordeal of graduating from high school and FRC last year, I am faced with not being able to test anything beyond compile time. So, I leave it open to everyone else to test out :D
Between college and working with the GCC devs I haven't had time to update the whole buildsystem yet, but EXPECT TO SEE BINARY PACKAGES SOON :D
For those of you who can't wait, here's how you can build GCC for vxworks on your very own:
NOTE: Lines starting with # must be run as root, and you need to have gcc, flex, bison, libmpfr-dev, libgmp-dev, libmpc-dev (or whatever the equivalents are for your distro) installed
NOTE2: If someone wants to mirror the snapshot of GCC that would be awesome as github has to dynamically regenerate it every time someone downloads it (though this is still faster than checking out on cvs...). I'd do it but my school doesn't like people tunneling out of their network...
# mkdir -p /usr/powerpc-wrs-vxworks/wind_base
# mkdir -p /usr/powerpc-wrs-vxworks/include
# echo 'export WIND_BASE=/usr/powerpc-wrs-vxworks/wind_base' >> /etc/profile
$ source /etc/profile
$ wget https://github.com/mirrors/gcc/archive/master.zip
$ wget http://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.bz2
$ wget ftp://ftp.ni.com/pub/devzone/tut/updated_vxworks63gccdist.zip
$ unzip gcc-master.zip
$ tar -jxf binutils-2.22.tar.bz2
$ unzip updated_vxworks63gccdist.zip
# mkdir -p $WIND_BASE/target
# cp -r gccdist/WindRiver/vxworks-6.3/host/. $WIND_BASE/host
# ln -s /usr/powerpc-wrs-vxworks/sys-include $WIND_BASE/target/h
# cp -r gccdist/WindRiver/vxworks-6.3/target/h/. /usr/powerpc-wrs-vxworks/sys-include
# ln -s sys-include/wrn/coreip /usr/powerpc-wrs-vxworks/include
$ mkdir binutils-build
$ cd binutils-build
$ ../binutils-2.22/configure --prefix=/usr --target=powerpc-wrs-vxworks --disable-nls
$ make -j4
# make install
$ cd ..
$ mkdir gcc-build
$ cd gcc-build
$ ../gcc-master/configure --prefix=/usr --target=powerpc-wrs-vxworks --with-gnu-as --with-gnu-ld --with-headers --disable-shared --disable-libssp --disable-multilib --with-float=hard --enable-languages=c,c++ --enable-threads=vxworks --without-gconv --disable-libgomp --disable-nls --disable-libmudflap --with-cpu-PPC603 --disable-symvers
$ make -j4
# make install
AND YOU'RE DONE!
That was a mouthful. This is why I will work to get those binaries out to you all soon :). Let me know if I made a typo. I haven't tested this as rigorously as I usually do for my builds, and I haven't rebuilt binutils in a while, but I wanted to get this out to you all early so that I could see if there's any runtime issues people run into.
HOW TO BUILD:
You can manually hack a UCPP makefile, OR, you can use cmake. Links:
https://github.com/rbmj/cmake_vxworks
and, to build a better WPILib (I mean, they had to make the compiler's optimizations better since 3.x :D) and ensure there are no symbol/ABI conflicts, go here:
https://github.com/rbmj/wpilib
I submitted the necessary patches to firstforge at the end of last season, but they have a pretty closed development model... Also, I'm not sure how much they are into supporting unofficial toolchains, though technically all of the changes are necessary for standards compliance as old GCC accepts stuff it shouldn't... but I digress.
Lobby FIRST/WRS/NI to use a compiler that *isn't* ten years old!
[BUGS/TODO]:
Also, a very broken build of fortran can be made by using --enable-languages=c,c++,fortran. However, this misconfigures itself horribly, so you'll need to go in and edit the config.h file by hand *bleh*. Go support is also in the works. However, at least for me, these are both lower priorities unless people here say they're really interested in these, as they aren't currently used by FRC. Also know, that the best way to get this done faster if you care is to do it yourself :) Just share with everyone else too!
The entire C++11 standard library (as it is/will be known by GCC 4.8 - freeze should be this week, so no major changes) *should* work. There might be one minor bug in thread-specific data corner cases, but other than that, please test all of the new features you can think of! And then use them so we don't have spaghetti code! TEST TEST TEST TEST PLEASE!
Lobby FIRST/WRS/NI to use a compiler that *isn't* ten years old!
Why ? Having a C compiler that is ten years old should be solid, reliable, and mature.
Just like all those old mentors that volunteer for FIRST !!
agartner01
04-11-2012, 11:28
Why ? Having a C compiler that is ten years old should be solid, reliable, and mature.
Why doesn't everyone just use 6 wheel tank drive, which is arguably more solid and reliable?
Andrew Schreiber
04-11-2012, 11:52
Why doesn't everyone just use 6 wheel tank drive, which is arguably more solid and reliable?
Same reason not everyone uses C for every task. :rolleyes:
CodeYeti
04-11-2012, 13:25
Why ? Having a C compiler that is ten years old should be solid, reliable, and mature.
Just like all those old mentors that volunteer for FIRST !!
Support for other languages
Native builds on different host OSs
agartner01
04-11-2012, 15:41
Yeah, I can't even get it to compile. It looks like it fails with:
/bin/bash: MULTIDIR: command not found
which I googled and found nothing conclusive. Is there a way to fix this?
Would it be possible to just zip the /usr/powerpc-wrs-vxworks folder so I wouldn't have to worry about it?
Why ? Having a C compiler that is ten years old should be solid, reliable, and mature.
Just like all those old mentors that volunteer for FIRST !!
Why do we even bother innovating anyway?
In all seriousness, because it runs natively on linux, supports c++11 and has much better compliance with c++03, has better optimizations, runs faster (AFAIK), and because IT'S SHINY AND NEW!
Also, WRT to the MULTIDIR thing, that's not a fatal error. Double-check that /usr/powerpc-wrs-vxworks/include is a symlink to sys-include/wrn/coreip. Make sure that /usr/powerpc-wrs-vxworks/sys-include contains files that make sense (vxWorks.h, stdio.h, etc.)
I was typing those commands into a post box, not into a terminal, so it might have a typo...
Hey, I'm just asking. I like shiny and new too. I'm all for innovation.
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.
I know there are substantial language compliance differences and I'm curious as to how that drills down the particular FRC application we deal with.
I'm all for innovation. I just want to know what the innovation is. That's all.
And thanks, I'm glad to see the project...
agartner01
04-11-2012, 23:07
Checked it again. Still not able to compile. Heres what I get:
/bin/bash: MULTIDIR: command not found
/bin/bash: MULTIDIR: command not found
/home/alex/gcc-build/./gcc/as: 87: exec: /usr/powerpc-wrs-vxworks/bin/as: not found
make[2]: *** [tramp_s.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/home/alex/gcc-build/./gcc/as: 87: exec: /usr/powerpc-wrs-vxworks/bin/as: not found
make[2]: *** [enable-execute-stack.o] Error 1
/home/alex/gcc-build/./gcc/as: 87: exec: /usr/powerpc-wrs-vxworks/bin/as: not found
make[2]: *** [eabi_s.o] Error 1
/home/alex/gcc-build/./gcc/as: 87: exec: /usr/powerpc-wrs-vxworks/bin/as: not found
make[2]: *** [unwind-dw2.o] Error 1
make[2]: Leaving directory `/home/alex/gcc-build/powerpc-wrs-vxworks/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/alex/gcc-build'
make: *** [all] Error 2
Which makes sense because /usr/powerpc-wrs-vxworks/bin/as dosen't exist... Not sure if it's supposed to?
Also included an overview of the powerpc-wrs-vxworks folder.
I can't answer for the risks associated with using a new GCC. However, I can say that some of the standard library and language compliance benefits are very interesting and useful, particularly C++11 features. Additionally, should one discover any issues, the developers are much more likely to help you with a modern, developed version.
It is to both VxWorks' and GCC's benefit to keep compatibility current and not let it bitrot.
Again, a major motivating factor is to be able to get a native linux version. IN MY EXPERIENCE, the whole development process is smoother on linux, and not using the giant hulking behemoth that eclipse (and thus workbench) is makes development go much more quickly. CMake also does a better job of dependency tracking than the Makefiles that are generated by workbench or UCPP (no offense of course to the people who have been working on UCPP, which is an awesome project).
Checked it again. Still not able to compile. Heres what I get:
/bin/bash: MULTIDIR: command not found
/bin/bash: MULTIDIR: command not found
/home/alex/gcc-build/./gcc/as: 87: exec: /usr/powerpc-wrs-vxworks/bin/as: not found
make[2]: *** [tramp_s.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/home/alex/gcc-build/./gcc/as: 87: exec: /usr/powerpc-wrs-vxworks/bin/as: not found
make[2]: *** [enable-execute-stack.o] Error 1
/home/alex/gcc-build/./gcc/as: 87: exec: /usr/powerpc-wrs-vxworks/bin/as: not found
make[2]: *** [eabi_s.o] Error 1
/home/alex/gcc-build/./gcc/as: 87: exec: /usr/powerpc-wrs-vxworks/bin/as: not found
make[2]: *** [unwind-dw2.o] Error 1
make[2]: Leaving directory `/home/alex/gcc-build/powerpc-wrs-vxworks/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/alex/gcc-build'
make: *** [all] Error 2
Which makes sense because /usr/powerpc-wrs-vxworks/bin/as dosen't exist... Not sure if it's supposed to?
Also included an overview of the powerpc-wrs-vxworks folder.
It should exist. Did your build of binutils succeed, and did you make install successfully? That should have created a bunch of stuff in /usr/powerpc-wrs-vxworks/bin.
agartner01
04-11-2012, 23:53
It should exist. Did your build of binutils succeed, and did you make install successfully? That should have created a bunch of stuff in /usr/powerpc-wrs-vxworks/bin.
Alright, re-ran the binutils build and now it looks like it builds alright. I went ahead and installed too. I ran cmake on wpilib and get this error:
/usr/lib/gcc/powerpc-wrs-vxworks/4.8.0/../../../../powerpc-wrs-vxworks/bin/ld:
cannot find -lstdc++
Alright, re-ran the binutils build and now it looks like it builds alright. I went ahead and installed too. I ran cmake on wpilib and get this error:
/usr/lib/gcc/powerpc-wrs-vxworks/4.8.0/../../../../powerpc-wrs-vxworks/bin/ld:
cannot find -lstdc++
OK, I made a quick mistake. Re-run configure for GCC with the argument --enable-libstdcxx, then run make and make install again, and you should be good.
I can't seem to edit my original post anymore, so please do this or you will get errors...
agartner01
05-11-2012, 09:22
Ok, now it get this:
/usr/bin/powerpc-wrs-vxworks-c++ -nostdlib -r -Wl,-X -static
CMakeFiles/cmTryCompileExec2792526235.dir/testCXXCompiler.cxx.obj -o
cmTryCompileExec2792526235_PartialImage.out -lsupc++ -lstdc++ -lgcc
/usr/local/powerpc-wrs-vxworks/munch.sh powerpc-wrs-vxworks-nm
cmTryCompileExec2792526235_ctdt.c
cmTryCompileExec2792526235_PartialImage.out
Error running link command: No such file or directory
Edit:
The CMake Toolchain file should work with the standard "gccdist" toolchain. If you download this toolchain <1> then the cmake file should work fine (NOTE: It requires munch.sh and strip_syms.sh from the vxworks-gcc-patches repo to be installed in WIND_BASE - maybe should make these a separate package), just set TOOLCHAIN_IS_GCCDIST to true.
So I did that, now i get:
/usr/lib/gcc/powerpc-wrs-vxworks/4.8.0/../../../../powerpc-wrs-vxworks/bin/ld:
cannot open linker script file
/usr/local/powerpc-wrs-vxworks/wind_base/target/h/tool/gnu/ldscripts/link.OUT:
No such file or directory
collect2: error: ld returned 1 exit status
make[1]: *** [cmTryCompileExec1263306447] Error 1
That's a known bug. Look in the old thread, make the symlinks described, and you should be good.
I haven't been updating the toolchain file as I've been *very* busy working with the GCC devs to get everything working on VxWorks out-of-the-box. Again, this is still experimental until I get everything updated and get some binary packages out. I wanted to give the adventurous a chance to play around with it in advance though :)
agartner01
05-11-2012, 12:14
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!
agartner01
05-11-2012, 21:48
Robot code build completes but gives this error:
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"
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...
CodeYeti
06-11-2012, 14:02
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.
CodeYeti
06-11-2012, 14:08
Robot code build completes but gives this error:
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.
-set(TOOLCHAIN_PREFIX "/usr/local/powerpc-wrs-vxworks")
+set(TOOLCHAIN_PREFIX "/usr/powerpc-wrs-vxworks")
-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.
agartner01
12-11-2012, 22:56
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.
-set(TOOLCHAIN_PREFIX "/usr/local/powerpc-wrs-vxworks")
+set(TOOLCHAIN_PREFIX "/usr/powerpc-wrs-vxworks")
-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.
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:
/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...
/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:
-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:
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...
AustinSchuh
13-11-2012, 00:45
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.
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.
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.
CodeYeti
08-01-2013, 17:42
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.
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.
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.
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 :D
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:
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:
$ 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:
$ 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 :/
Forgot - these packages are signed with my public key. It's attached.
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?)
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.
agartner01
11-01-2013, 22:17
I've installed these packages, and I get errors during compile. I've tried it on two computer with Ubuntu 12.10 and am in the process of trying it on a clean VM. On the first computer, I don't get a "Could NOT find WPILib (missing: WPILib_INCLUDE_DIR)," but I do on the second. Both ultimately fail with, "fatal error: iostream.h: No such file or directory."
alex@gartner-pc:~/robotics-workspace/Simple/build$ frcmake ../src
-- Could NOT find WPILib (missing: WPILib_INCLUDE_DIR)
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_TOOLCHAIN_FILE
-- Build files have been written to: /home/alex/robotics-workspace/Simple/Untitled Folder
alex@gartner-pc:~/robotics-workspace/Simple/build$ make
[100%] Building CXX object CMakeFiles/robot_module.dir/MyRobot.cpp.obj
In file included from /home/alex/robotics-workspace/Simple/src/MyRobot.cpp:1:0:
/usr/powerpc-wrs-vxworks/include/WPILib/WPILib.h:11:22: fatal error: iostream.h: No such file or directory
#include <iostream.h>
^
compilation terminated.
make[2]: *** [CMakeFiles/robot_module.dir/MyRobot.cpp.obj] Error 1
make[1]: *** [CMakeFiles/robot_module.dir/all] Error 2
make: *** [all] Error 2
alex@gartner-pc:~/robotics-workspace/Simple/build$
I've installed these packages, and I get errors during compile. I've tried it on two computer with Ubuntu 12.10 and am in the process of trying it on a clean VM. On the first computer, I don't get a "Could NOT find WPILib (missing: WPILib_INCLUDE_DIR)," but I do on the second.
Can you tell me what you find in WPILibConfig.cmake and WPILibConfigVersion.cmake in /usr/powerpc-wrs-vxworks/share/WPILib/cmake, and check that any variables set in there are correct?
Both ultimately fail with, "fatal error: iostream.h: No such file or directory."
alex@gartner-pc:~/robotics-workspace/Simple/build$ frcmake ../src
-- Could NOT find WPILib (missing: WPILib_INCLUDE_DIR)
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_TOOLCHAIN_FILE
-- Build files have been written to: /home/alex/robotics-workspace/Simple/Untitled Folder
alex@gartner-pc:~/robotics-workspace/Simple/build$ make
[100%] Building CXX object CMakeFiles/robot_module.dir/MyRobot.cpp.obj
In file included from /home/alex/robotics-workspace/Simple/src/MyRobot.cpp:1:0:
/usr/powerpc-wrs-vxworks/include/WPILib/WPILib.h:11:22: fatal error: iostream.h: No such file or directory
#include <iostream.h>
^
compilation terminated.
make[2]: *** [CMakeFiles/robot_module.dir/MyRobot.cpp.obj] Error 1
make[1]: *** [CMakeFiles/robot_module.dir/all] Error 2
make: *** [all] Error 2
alex@gartner-pc:~/robotics-workspace/Simple/build$
Well, that's an error in WPILib. <iostream.h> is non-standard and hasn't existed for some time - the compiler is right to throw an error there. Thanks for catching that - I've never included <WPILib.h> in my own code (and incidentally, neither does WPILib, as otherwise I would have caught the error earlier). For now just manually change it to <iostream>. The patch is in my github repo. I'm opening another bug on WPILib for all sorts of code that won't compile with a modern compiler - hopefully they listen this time...
Due to it being a pain to regenerate all the binaries no re-upload yet. Those who want the latest and greatest can as always grab it off github. Compiling WPILib is as simple as frcmake, make, make install.
agartner01
11-01-2013, 23:52
Can you tell me what you find in WPILibConfig.cmake and WPILibConfigVersion.cmake in /usr/powerpc-wrs-vxworks/share/WPILib/cmake, and check that any variables set in there are correct?
I believe the variables are set correctly, I've attached the files.
I've also made the change from <iostream> and things appear to compile alright. I've attached my current build output since there is still the WPILib error. I'll be testing it on the crio either tomorrow or Sunday.
Edit: I've tested your packages in a clean Ubuntu 12.10 VM, and I've encountered a different error. See VMerror.txt for details.
CodeYeti
12-01-2013, 15:11
Well I've managed to get everything compiling alright, and now that we have our hardware, I've been trying to test things on hardware. Right now the kernel module is failing to load. The netconsole output is as follows:
Warning: module 0xe780b8 (FRC_UserProgram.out) holds reference to undefined symbol _ZN14IterativeRobot16TeleopContinuoutEv
<more errors similar to the one above>
...FRC_UserProgram failed to load.
Any help is appreciated. Thanks!
CodeYeti
12-01-2013, 15:30
Ok I've gotten that fixed. For some reason, my build of WPILib had been corrupted and I just had to make clean and make gain. Now I've got a similar error that hasn't been so easy to fix:
Warning: module 0xe 78118 (FRC_UserProgram.out) holds reference to undefined symbol _start.
(unloading partially loaded module FRC_UserProgram.out)
...FRC_UserProgram failed to load.
Thanks in advance for the help and sorry for the double post.
agartner01
12-01-2013, 15:55
Ok I've gotten that fixed. For some reason, my build of WPILib had been corrupted and I just had to make clean and make gain. Now I've got a similar error that hasn't been so easy to fix:
Warning: module 0xe 78118 (FRC_UserProgram.out) holds reference to undefined symbol _start.
(unloading partially loaded module FRC_UserProgram.out)
...FRC_UserProgram failed to load.
Thanks in advance for the help and sorry for the double post.
I'd just like to add that I get the same error. Net console output is attached.
CodeYeti
12-01-2013, 16:09
Alright well I edited the strip_syms.sh script to dump its syms to my home directory. It's not stripping off _start so thats not the issue. Just thought I'd share as I'm debugging.
EDIT: It's probably worth noting that I'm working on OSX.
EDIT2: If you make any progress, no matter how small, please don't hesitate to share.
Thank you both for testing. I knew something would happen like this with no testbed. It's probably a compiler flag issue. I'm going to look at it in objdump and see where the reference is...
CodeYeti
12-01-2013, 20:59
Thanks again for all your work on this, and updating for the new wpilib in a timely manner. You've seriously been great.
Anyways, I noticed you've added a WPILibConfig.cmake file to the wpilib project. Why did you decide to move away from the find module. AFAIK, the find module is the "accepted/correct" way to go about it.
Thanks again for all your work on this, and updating for the new wpilib in a timely manner. You've seriously been great.
Anyways, I noticed you've added a WPILibConfig.cmake file to the wpilib project. Why did you decide to move away from the find module. AFAIK, the find module is the "accepted/correct" way to go about it.
Two reasons:
1. laziness
2. it's a lot easier to do version checking with Config files, and some programmers might want to codify a dependency on a particular release of WPILib in the build system.
CodeYeti
12-01-2013, 21:40
Two reasons:
1. laziness
2. it's a lot easier to do version checking with Config files, and some programmers might want to codify a dependency on a particular release of WPILib in the build system.
Ahh version checking sure would be nice.
Still, if anybody still wants the old WPILib find module (I'll still be doing things that way I think). I'll keep it updated for rbmj's toolchain packages.
http://github.com/mcoffin/cmake-wpilib
agartner01
12-01-2013, 21:52
Thank you both for testing. I knew something would happen like this with no testbed. It's probably a compiler flag issue. I'm going to look at it in objdump and see where the reference is...
If you wanted to remote desktop in and look at the crio yourself (that might accelerate the debugging process), just say the word and I'll set it up.
OK, so I looked at a disassembly of my own code. I can already tell that the final link (the one that creates <TARGET>) is introducing the problem. Now, AFAIK this shouldn't happen due to -nostdlib, which implies -nostartfiles, as I *think* that's what introduces _start to the symbol table.
I looked at a disassembly of the code and ran a search for _start. It isn't called anywhere, so I don't see why it needs to reference _start. VxWorks also doesn't care about _start as it has it's own entry points.
I believe that something like the following would work as a temporary workaround:
extern "C" {
void _start() {
//output an error message?
}
}
As I believe it should never be called, I doubt this would be an issue. Then, for completeness' sake one should add "-L _start" to the objcopy command in powerpc-wrs-vxworks-munch. That way you don't pollute the kernel namespace with unnecessary symbols.
I also don't recalling this problem happening with old GCC. Therefore, I'm going to try a year old version of GCC and see if it still has this issue. If not, than it's a regression in the compiler. If I know this is the case, I can run a git bisect and determine exactly where this happened. I'm 90% sure it'll work with last march's gcc (as I seem to remember it working), so that's about 9 months. According to git there have been ~8800 commits in the past 9 months, and log2(8800) is about 13. So, thanks to the wonders of binary search, I can figure out what broke it. Then, that's just a bug report. I should be able to script it (I think [ `nm <TARGET> | grep _start | wc -l` -eq 1 ] will work as a testcase on the compilation).
I don't have that long though... GCC is in the last stage of development before release. This should count as a pretty serious regression though if it is what I think it is.
Sorry, thinking on forum. It helps me work it out...
Is that the ONLY unresolved symbol error you get?
EDIT: Nvm just checked the netconsole output. Thanks again for that. To be quite honest, this is better than I expected, considering how often these things can break.
CodeYeti
13-01-2013, 00:45
OK, so I looked at a disassembly of my own code. I can already tell that the final link (the one that creates <TARGET>) is introducing the problem. Now, AFAIK this shouldn't happen due to -nostdlib, which implies -nostartfiles, as I *think* that's what introduces _start to the symbol table.
I looked at a disassembly of the code and ran a search for _start. It isn't called anywhere, so I don't see why it needs to reference _start. VxWorks also doesn't care about _start as it has it's own entry points.
I believe that something like the following would work as a temporary workaround:
extern "C" {
void _start() {
//output an error message?
}
}
As I believe it should never be called, I doubt this would be an issue. Then, for completeness' sake one should add "-L _start" to the objcopy command in powerpc-wrs-vxworks-munch. That way you don't pollute the kernel namespace with unnecessary symbols.
I also don't recalling this problem happening with old GCC. Therefore, I'm going to try a year old version of GCC and see if it still has this issue. If not, than it's a regression in the compiler. If I know this is the case, I can run a git bisect and determine exactly where this happened. I'm 90% sure it'll work with last march's gcc (as I seem to remember it working), so that's about 9 months. According to git there have been ~8800 commits in the past 9 months, and log2(8800) is about 13. So, thanks to the wonders of binary search, I can figure out what broke it. Then, that's just a bug report. I should be able to script it (I think [ `nm <TARGET> | grep _start | wc -l` -eq 1 ] will work as a testcase on the compilation).
I don't have that long though... GCC is in the last stage of development before release. This should count as a pretty serious regression though if it is what I think it is.
Sorry, thinking on forum. It helps me work it out...
Is that the ONLY unresolved symbol error you get?
EDIT: Nvm just checked the netconsole output. Thanks again for that. To be quite honest, this is better than I expected, considering how often these things can break.
I'll see if I can get out to the build space tomorrow and give that a test. Could be more errors we don't know about. If not, I'll definitely have something to tell you on Monday. Thanks for the work. Should I even bother try adding the -nostartfiles flag explicitly instead of implicitly?
agartner01
13-01-2013, 00:48
I'll try the fix on Sunday. If you want to give me a .out from the old compiler to test, feel free to post it (or upload it somewhere) and I'll test it out.
CodeYeti
13-01-2013, 01:04
I'll try the fix on Sunday. If you want to give me a .out from the old compiler to test, feel free to post it (or upload it somewhere) and I'll test it out.
I can't really sleep so I'm starting to do the binary searching. Do you have a cRIO with you now or no?
agartner01
13-01-2013, 01:06
I can't really sleep so I'm starting to do the binary searching. Do you have a cRIO with you now or no?
No it's at my school... Was thinking about taking the test bed home but that didn't happen...
Edit: I'm not sure if this's relevant, I just though of something else. Previous attempts also yielded the "_start" symbol error. However, they also gave a "relocation value does not fit within 24 bits" error, while this attempt did not.
CodeYeti
13-01-2013, 01:16
No it's at my school... Was thinking about taking the test bed home but that didn't happen...
Edit: I'm not sure if this's relevant, I just though of something else. Previous attempts also yielded the "_start" symbol error. However, they also gave a "relocation value does not fit within 24 bits" error, while this attempt did not.
Well its good to know that something got fixed. I asked my mentors to take a cRIO with me, but they weren't too keen on the idea either. How old of an attempt are we talking about here?
agartner01
13-01-2013, 01:21
Well its good to know that something got fixed. I asked my mentors to take a cRIO with me, but they weren't too keen on the idea either. How old of an attempt are we talking about here?
Both results from the old post (http://www.chiefdelphi.com/forums/showpost.php?p=1187694&postcount=22) and this post (http://www.chiefdelphi.com/forums/showpost.php?p=1192982&postcount=17) gave me these errors. I'm assuming it was an error on my part...
I can actually do the binary search without a cRIO, as (once I know what to look for) I can have a script determine if it holds a reference to _start.
I'm working on getting a setup to compile a patched old compiler now.
Edit: Compiling last march's gcc with the patches. Let's see if this one works.
OK, I can confirm that it's a flag issue, not a compiler issue. Now just to determine which one...
agartner01
13-01-2013, 12:31
Alright, I've tested the fix of the "_start" symbol error, and it appears that everything is now working. Yay! I've also included netconsole output as proof.
Edit: I'd still like to resolve the errors I encountered during the VM installation, detailed in this post. (http://www.chiefdelphi.com/forums/showpost.php?p=1213457&postcount=33)
OK, so after some testing it looks like it's a problem with the link script. I'll investigate further.
Also, the new packages do not require you to set WIND_BASE as they install a script to set it in /etc/profile.d. As long as your /etc/profile will source everything in /etc/profile.d (which is the default in modern debian and I think thus modern ubuntu), don't bother setting that. The issue is that the toolchain file looks in the environment for WIND_BASE and goes off of that, which for this toolchain MUST be /usr/powerpc-wrs-vxworks/wind_base.
CodeYeti
13-01-2013, 14:12
OK, I can confirm that it's a flag issue, not a compiler issue. Now just to determine which one...
Could it be a problem with the compiler configuration as well? IIRC from a while back, libmudflap had a reference to _start. Was a --disable flag maybe forgotten when configuring the compiler?
Just an idea. I don't have access to a cRIO just this second so I can't test much other than just looking at objdumps.
I must have originally forgotten to use the link script when I checked things, as the script has ENTRY(_start) in it. Either that, or an update to ld where originally it would ignore this directive if it couldn't find the symbol but now adds it in as an unresolved symbol. I don't know which.
I'm modifying the wrs-headers-installer script to make a new ld script. Unfortunately the update is going to require you to re-download gccdist and everything as I don't have time to do the upgrade "correctly". Therefore, I won't change the version, and I'll give you a script that will perform the update.
OK, so at the original download link I've updated the buildscripts and wrs-headers-installer packages. Since they're still considered beta I'm not upgrading the versions, but if you install with dpkg it will still overwrite.
If you have the old wrs-headers-installer package, you do not need to update that package, but you do need to update the buildscripts package. You also need to run this:
# mkdir -p /usr/powerpc-wrs-vxworks/share/ldscripts
# sed '/ENTRY(_start)/d' < /usr/powerpc-wrs-vxworks/wind_base/target/h/tool/gnu/ldscripts/link.OUT > /usr/powerpc-wrs-vxworks/share/ldscripts/dkm.ld
Note that that needs to be run as root - I would use su (or sudo su), not sudo as sudo sometimes has issues with io redirection (in my experience).
Once you've run those commands, verify that /usr/powerpc-wrs-vxworks/share/ldscripts/dkm.ld exists and has content in it.
If you do this, that should fix the unresolved symbol error for _start.
FWIW, I've submitted the patch to the WPILib tracker. I'm not sure if it'll come to anything, but w/e.
Open source does not mean open development...
Thanks all for your help in debugging this! Hopefully this will fix things. A preliminary build of my team's code from last year works, and I can't find any of the usual suspect errors that I can catch by looking at the binaries with binutils.
agartner01
13-01-2013, 18:39
OK, so at the original download link I've updated the buildscripts and wrs-headers-installer packages. Since they're still considered beta I'm not upgrading the versions, but if you install with dpkg it will still overwrite.
If you have the old wrs-headers-installer package, you do not need to update that package, but you do need to update the buildscripts package. You also need to run this:
# mkdir -p /usr/powerpc-wrs-vxworks/share/ldscripts
# sed '/ENTRY(_start)/d' < /usr/powerpc-wrs-vxworks/wind_base/target/h/tool/gnu/ldscripts/link.OUT > /usr/powerpc-wrs-vxworks/share/ldscripts/dkm.ld
Note that that needs to be run as root - I would use su (or sudo su), not sudo as sudo sometimes has issues with io redirection (in my experience).
Once you've run those commands, verify that /usr/powerpc-wrs-vxworks/share/ldscripts/dkm.ld exists and has content in it.
If you do this, that should fix the unresolved symbol error for _start.
It doesn't, as far as I can see... Updated both the buildscripts and wrs headers, removed the fix from my code, and then got a "_start symbol" error. I then attempted to run the code you posted, but that didn't solve it either...
Edit: I'm sorry, I started a new project and things worked just fine...
I started a new project and things worked just fine...
:D Awesome!
CodeYeti
13-01-2013, 22:54
Things are working well here as well, though it seems that I'm unable to use any of the C++11 memory management features. It fails at compile time, saying that std::unique_ptr doesn't refer to a type. Aren't these supposed to work? If not, why? (Just curious).
Unfortunately I can't find a way to get C++11 to work either. I remembered it working a while ago however this does not appear to be the case.
I'll send a message to gcc-help asking about this.
Redefine __cplusplus to 201103L at the top of your source file and watch the barf spew from the compiler...
OK, I've determined the cause of the c++11 failures - turns out it was my own stupidity.
I have classes so I don't have time to regen the packages until this weekend, but the quick fix is to go into /usr/powerpc-wrs-vxworks/share/cmake/toolchain.cmake, look for the line containing -ansi, and remove -ansi from that line. Then, when you call cmake, use:
$ frcmake $SRCDIR -DCMAKE_CXX_FLAGS='-std=c++11 -fpermissive'
I don't want to make this default yet as there's still a few issues in WPILib with C++11 compatibility and I don't want to mess up people who are happy with c++98
CodeYeti
15-01-2013, 14:49
OK, I've determined the cause of the c++11 failures - turns out it was my own stupidity.
I have classes so I don't have time to regen the packages until this weekend, but the quick fix is to go into /usr/powerpc-wrs-vxworks/share/cmake/toolchain.cmake, look for the line containing -ansi, and remove -ansi from that line. Then, when you call cmake, use:
$ frcmake $SRCDIR -DCMAKE_CXX_FLAGS='-std=c++11 -fpermissive'
I don't want to make this default yet as there's still a few issues in WPILib with C++11 compatibility and I don't want to mess up people who are happy with c++98
Would you mind giving a few details on whats up with WPILib and C++11 so I can either work the problems out or avoid situations in which they would be a problem?
The biggest thing is that GCC seems to conform to the standard more strictly in c++11 mode than in c++98 mode. In C++98 mode it is technically wrong to declare and initialize a static constant of non-integral type in a header file, however gcc accepts it. However, with c++11 and the constexpr keyword there is an easy workaround so gcc wants you to use constexpr instead of const. This causes compile errors, though these can be downgraded to warnings with the -fpermissive flag. However, I feel uncomfortable adding this flag in as I believe that code should conform to the standard and be warning-free. Although in some cases these are merely stylistic concerns, I think that in many cases these can highlight a bug or undefined behavior. This is why I enable -Wall in the toolchain file.
I'm working on cleaning up the WPILib headers so that they won't fire off warnings. This way they don't fill up the build log for the end user. Library headers that fire warnings are at best annoying and at worst can overwhelm valuable output from the compiler.
CodeYeti
16-01-2013, 00:06
The biggest thing is that GCC seems to conform to the standard more strictly in c++11 mode than in c++98 mode. In C++98 mode it is technically wrong to declare and initialize a static constant of non-integral type in a header file, however gcc accepts it. However, with c++11 and the constexpr keyword there is an easy workaround so gcc wants you to use constexpr instead of const. This causes compile errors, though these can be downgraded to warnings with the -fpermissive flag. However, I feel uncomfortable adding this flag in as I believe that code should conform to the standard and be warning-free. Although in some cases these are merely stylistic concerns, I think that in many cases these can highlight a bug or undefined behavior. This is why I enable -Wall in the toolchain file.
I'm working on cleaning up the WPILib headers so that they won't fire off warnings. This way they don't fill up the build log for the end user. Library headers that fire warnings are at best annoying and at worst can overwhelm valuable output from the compiler.
Cool. I'll probably join in on working with WPILib. Who knows, we might find a bug! The java version actually had a sine and cosine flipped two years ago.
Beat you to it:
http://firstforge.wpi.edu/sf/go/artf1578?returnUrlKey=1358334177246
:D
CodeYeti
16-01-2013, 17:45
Hi there! I've been reluctant to install via the packages due to my infinitely small understanding of aptitude packages. I've installed the new build scripts though since there are updates to the toolchain file in there. I just installed with the following commands after checking out the powerpc-wrs-vxworks-buildscripts repo.
cmake .
make && sudo make install
The new ld script that the toolchain file now references for non-gccdist toolchains doesn't appear to be in my compiler installation. Is there somewhere where I should be getting it, or is installed by a package?
Also: should I just switch to the packages, even if I'm planning on actively developing if I find a bug/missing feature?
The link script is generated by the wrs-headers-installer package. I was not sure which package it would be more suitable in, and I ended up picking the wrs-headers-installer package, since that handles all the other proprietary information.
CodeYeti
16-01-2013, 18:19
Thanks. I need to do some reading on how aptitude packages work from a non-user perspective. Since I have a meeting tonight, and kinda want to toy with C++11 and wpilib, would you mind just giving me a quick instruction on how to build the packages? (I can install them and all that jazz, but I haven't really developed with aptitude before).
Thanks again for the patience and your awesome contributions to FIRST.
BEGIN EDIT
Just tried building GCC on my debian machine from source. I've gotten a pretty odd error. Might a recent commit have broken something?
../../../gcc-master/libgcc/libgcov.c: In function 'create_file_directory':
../../../gcc-master/libgcc/libgcov.c:143:13: error: too many arguments to function 'mkdir'
&& mkdir (filename, 0755) == -1
^
In file included from ../../../gcc-master/libgcc/libgcov.c:82:0:
/usr/local/powerpc-wrs-vxworks/wind_base/target/h/sys/stat.h:169:24: note: declared here
extern STATUS mkdir (const char *_dirName);
^
make[2]: *** [_gcov.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/home/mcoffin/gcc-build/powerpc-wrs-vxworks/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/mcoffin/gcc-build'
make: *** [all] Error 2
CodeYeti
16-01-2013, 19:21
Sorry for the double post, but my edit button went away. Anyways, I've started fixing up wpilib to fit GCC's idea of the C++11 standard. It's in a branch called cxx11 in my fork of your wpilib repository.
http://github.com/mcoffin/wpilib
Once you have debhelper and devscripts et al installed, it's not too bad. You won't be able to sign the packages, but everything else will work. Buildscripts is easy - just run ./debmake and it should work automatically. Beware, however, that that script will make the latest commit in the git repo, so you need to commit any changes before they will go into the package.
For the other packages, the basic workflow is this:
1. create or download/rename a pkgname_version.orig.tar.gz file. It should extract to pkgname-version.
2. extract this archive, and go into the the created source directory
3. If the source doesn't have a debian subdirectory, copy the debian subdirectory into the source from my git repo
4. run debuild -us -uc. This will create but not sign the packages. If you want to sign the packages yourself you'll need to make a key and make a new changelog entry with the dch command, making sure that the name, nickname (you might have to add this in manually), and email match EXACTLY your key's info.
note that in order to not conflict with the packages that debian will build, many of the packages are named powerpc-wrs-vxworks-name. That's what you use for package name. Additionally, these directories don't have version numbers, so you either have to rename the directory or make a new copy of the repo.
As an exception, you need to add -e WIND_BASE when you call debuild for gcc.
I highly suggest that you do your homework though. The debian buildsystem is very powerful, but it's not exactly simple, and there are a LOT of gotchas.
As far as your gcc error goes, looks like something's up with fixincludes (again). Double check to make sure that fixincludes is running, and if that doesn't work, look inside your gcc build directory (not top level, but the gcc build directory itself), find include-fixed, and look in there for sys/stat.h. Once you have determined that that file exists, look for a variadic macro for mkdir.
If that file does not exist, tell me which files do in the include-fixed directory.
EDIT: I'm looking at the way that you fixed WPILib. Good job on fixing all those constexpr issues, however we need to maintain compatibility with c++98. You probably need to test #if __cplusplus < 201103L and have a macro that selects the correct const-incantation for different versions of c++. My perspective is that we should strive for integration with upstream as much as possible (even if development is rather closed off) as I do not have or want to put in the time and energy necessary to maintain a full fork. This is why I worked so hard to get the patches merged in to GCC itself - so all those hacks were no longer necessary, and we weren't going after a moving target. And, to return to the point, there's no way that they'll accept any changes that break compatibility with c++98.
IF the community wants a more openly developed version of WPILib, OK. We can put in the work to make that happen if it's a goal (primarily meaning make it easy to integrate with ucpp and standard WindRiver. If we can react to bug reports on CD faster than upstream, then that might be a feature justifying a fork. However, as much as the long time between bugfixes and the secret development of WPILib irks me, I don't see a large enough demand to justify a fork.
CodeYeti
16-01-2013, 23:52
Once you have debhelper and devscripts et al installed, it's not too bad. You won't be able to sign the packages, but everything else will work. Buildscripts is easy - just run ./debmake and it should work automatically. Beware, however, that that script will make the latest commit in the git repo, so you need to commit any changes before they will go into the package.
For the other packages, the basic workflow is this:
1. create or download/rename a pkgname_version.orig.tar.gz file. It should extract to pkgname-version.
2. extract this archive, and go into the the created source directory
3. If the source doesn't have a debian subdirectory, copy the debian subdirectory into the source from my git repo
4. run debuild -us -uc. This will create but not sign the packages. If you want to sign the packages yourself you'll need to make a key and make a new changelog entry with the dch command, making sure that the name, nickname (you might have to add this in manually), and email match EXACTLY your key's info.
note that in order to not conflict with the packages that debian will build, many of the packages are named powerpc-wrs-vxworks-name. That's what you use for package name. Additionally, these directories don't have version numbers, so you either have to rename the directory or make a new copy of the repo.
As an exception, you need to add -e WIND_BASE when you call debuild for gcc.
I highly suggest that you do your homework though. The debian buildsystem is very powerful, but it's not exactly simple, and there are a LOT of gotchas.
As far as your gcc error goes, looks like something's up with fixincludes (again). Double check to make sure that fixincludes is running, and if that doesn't work, look inside your gcc build directory (not top level, but the gcc build directory itself), find include-fixed, and look in there for sys/stat.h. Once you have determined that that file exists, look for a variadic macro for mkdir.
If that file does not exist, tell me which files do in the include-fixed directory.
EDIT: I'm looking at the way that you fixed WPILib. Good job on fixing all those constexpr issues, however we need to maintain compatibility with c++98. You probably need to test #if __cplusplus < 201103L and have a macro that selects the correct const-incantation for different versions of c++. My perspective is that we should strive for integration with upstream as much as possible (even if development is rather closed off) as I do not have or want to put in the time and energy necessary to maintain a full fork. This is why I worked so hard to get the patches merged in to GCC itself - so all those hacks were no longer necessary, and we weren't going after a moving target. And, to return to the point, there's no way that they'll accept any changes that break compatibility with c++98.
IF the community wants a more openly developed version of WPILib, OK. We can put in the work to make that happen if it's a goal (primarily meaning make it easy to integrate with ucpp and standard WindRiver. If we can react to bug reports on CD faster than upstream, then that might be a feature justifying a fork. However, as much as the long time between bugfixes and the secret development of WPILib irks me, I don't see a large enough demand to justify a fork.
Sounds good. I'll have to get working on the compatibility issue. I've fixed all the errors, and some of the warnings for WPILib with C++11. I can confirm that at least the memory management features of C++11 work on hardware as of tonight!
The C++11 only version of WPILib is here: https://github.com/mcoffin/wpilib/tree/cxx11.
As for making sure we're backwards compatible, from what I've read, WPILib as it is shouldn't compile under C++98 either, it's just a fluke that GCC is playing loose with the standards there. Therefore, I think that when making a fix, it would be best to avoid the initialization of static constant members that are floats/doubles from within the class declaration all together. I think that the next best solution would just be to put them in the constructor? That would work on both standards, whereas the constexpr fix defining them as expressions would only work for C++11.
EDIT: The contents of include-fixed are as follows. I'm going to re-start from scratch just in case I missed a flag somewhere that caused fixincludes to mess up, but here are the contents in case I get the error again:
limits.h
README
syslimits.h
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
EDIT 3: Build error was just a fluke. I have no idea what happened. Deleted my build directory, reconfigured and it worked. That was pretty stupid on my part. Sorry for the hassle on that one.
EDIT 4: The virtual destructor warnings are legit. These are abstract classes with pure abstract methods, and the classes have derived classes. This means that if a derived class were to have an explicit destructor, it wouldn't be getting called. I'll be sure to fix those warnings in the next round of fixes.
EDIT 5: The master branch on my git repository should fix many of the compiler warnings for wpilib on C++98 as well. I haven't tested compatibility with old versions of GCC yet though. I did leave some unnecessary typedef's in there because I think that they, at some point, were necessary, so WindRiver's version of GCC might still want them and I don't want to break compatibility with it. The C++11 branch has these changes pulled in as well.
Sounds good. I'll have to get working on the compatibility issue. I've fixed all the errors, and some of the warnings for WPILib with C++11. I can confirm that at least the memory management features of C++11 work on hardware as of tonight!
The C++11 only version of WPILib is here: https://github.com/mcoffin/wpilib/tree/cxx11.
As for making sure we're backwards compatible, from what I've read, WPILib as it is shouldn't compile under C++98 either, it's just a fluke that GCC is playing loose with the standards there. Therefore, I think that when making a fix, it would be best to avoid the initialization of static constant members that are floats/doubles from within the class declaration all together. I think that the next best solution would just be to put them in the constructor? That would work on both standards, whereas the constexpr fix defining them as expressions would only work for C++11.
Ha yes, as it stands a *lot* of code shouldn't compile under C++98 either. However GCC 3.x is *very* lax with compliance. GCC 4 really stepped up on its strictness, which is great except it also causes cases like these. I think in c++98 mode there's a little more leniency built in just for backwards compatibility.
Well, if it's a static const you can:
//foo.h
class foo {
static const float bar;
};
//foo.cpp
#include "foo.h"
const float foo::bar = 1.0;
AFAIK that will work.
EDIT: The contents of include-fixed are as follows. I'm going to re-start from scratch just in case I missed a flag somewhere that caused fixincludes to mess up, but here are the contents in case I get the error again:
limits.h
README
syslimits.h
If you get this, that indicates that fixincludes was screwed up. If you look now you should see a *lot* more files. These are replacement headers that deal with the various errors in the actual headers
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
Agreed. This is an issue with vxWorks itself. Not much we can do here. If we wanted to we could add a rule to fixincludes, but I don't think a warning that we know to be spurious and can disable is worth the extra effort involved in getting accepted upstream or the complications of building patched source.
EDIT 3: Build error was just a fluke. I have no idea what happened. Deleted my build directory, reconfigured and it worked. That was pretty stupid on my part. Sorry for the hassle on that one.
No problem. Sometimes GCC builds fail for random unknown reasons...
EDIT 4: The virtual destructor warnings are legit. These are abstract classes with pure abstract methods, and the classes have derived classes. This means that if a derived class were to have an explicit destructor, it wouldn't be getting called. I'll be sure to fix those warnings in the next round of fixes.
And this is why we use compiler warnings! :D
EDIT 5: The master branch on my git repository should fix many of the compiler warnings for wpilib on C++98 as well. I haven't tested compatibility with old versions of GCC yet though. I did leave some unnecessary typedef's in there because I think that they, at some point, were necessary, so WindRiver's version of GCC might still want them and I don't want to break compatibility with it. The C++11 branch has these changes pulled in as well.
Awesome!
CodeYeti
17-01-2013, 14:21
So I'm getting better, but I'm still really stupid with debian packages. I've gotten the binutils installed, so I think I get the process for building these source packages. I downloaded a binutils tarball with wget and then added the debian directory from the git repository to the extracted folder (after renaming the original tarball to fit debian's naming scheme).
Now, I think I should probably install the wrs-headers-installer next, correct? How would I build that package? It's complaining that it can't find an upstream tarball (because I didn't download one). What am I supposed to do with that one? I tried ./debianize, but bash couldn't find dh_make.
Sorry for my noobyness in this area, I really just need to sit down and learn about aptitude a little more when I get the time.
EDIT: Looks like I've found the time, I'm just going through all the wiki pages and everything and doing a few examples with it. Just ignore the post, I'm sure I'll get it after just doing some learning. It's going to be more of a pain in the $@#$@#$@# in the long run to avoid spending the time learning it.
I'll upload the other files, which should help with building everything. These include .orig.tar.gz and .debian.tar.gz files IIRC.
The .orig files can be made with the following process with a git archive:
# in git archive for package $PKG
mkdir ../$PKG-$VERSION
git archive master | tar -x -C ../$PKG-$VERSION
cd ..
tar -cf $PKG_$VERSION.orig.tar $PKG-$VERSION
gzip $PKG_$VERSION.orig.tar
cd $PKG-$VERSION
debuild
Making these packages can be a pain in the rear. The debian/rules makefiles for gcc and wpilib are not code snippets I'm particularly proud of... but they work.
Also, if you make a mistake and the build dies, debian wants to completely rebuild the whole package from a distclean. So don't mess up when you're compiling GCC... you wouldn't believe how much time I wasted only to learn that I forgot to pass -e WIND_BASE to debuild...
CodeYeti
17-01-2013, 16:53
I'll upload the other files, which should help with building everything. These include .orig.tar.gz and .debian.tar.gz files IIRC.
The .orig files can be made with the following process with a git archive:
# in git archive for package $PKG
mkdir ../$PKG-$VERSION
git archive master | tar -x -C ../$PKG-$VERSION
cd ..
tar -cf $PKG_$VERSION.orig.tar $PKG-$VERSION
gzip $PKG_$VERSION.orig.tar
cd $PKG-$VERSION
debuild
Making these packages can be a pain in the rear. The debian/rules makefiles for gcc and wpilib are not code snippets I'm particularly proud of... but they work.
Also, if you make a mistake and the build dies, debian wants to completely rebuild the whole package from a distclean. So don't mess up when you're compiling GCC... you wouldn't believe how much time I wasted only to learn that I forgot to pass -e WIND_BASE to debuild...
I did the same thing, luckily, the first thing I did was check the config.log!
Regardless, ironically, I've got this stuff running on my mac via a manual install much better than I do on debian with the packages, but I'd love to help with development, and I want to stay current so I'm trying to switch over. Right now, theres something broken where its not finding the C++ includes (i.e. #include <string> won't work, etc) and I have no idea why. If anybody has run in to this, I'd appreciate a tip. Debugging as you're reading.
Also, just as a thought, since your debian package for wpilib has a builddep for cmake, and AFAIK, just invokes it, why don't you just use CPack? Seems like that would be a little bit cleaner solution, but that's just me.
EDIT: Still having that issue with the packages. I'm going to try the packages you built and see if that makes a difference. Just to make sure, I've been installing them in this order:
binutils
wrs-headers
gcc
buildscripts
Any help is appreciated.
I did the same thing, luckily, the first thing I did was check the config.log!
Regardless, ironically, I've got this stuff running on my mac via a manual install much better than I do on debian with the packages, but I'd love to help with development, and I want to stay current so I'm trying to switch over. Right now, theres something broken where its not finding the C++ includes (i.e. #include <string> won't work, etc) and I have no idea why. If anybody has run in to this, I'd appreciate a tip. Debugging as you're reading.
Never seen that one... thanks for all your work testing/fixing/debugging!
Also, just as a thought, since your debian package for wpilib has a builddep for cmake, and AFAIK, just invokes it, why don't you just use CPack? Seems like that would be a little bit cleaner solution, but that's just me.
Because CPack, though easy, doesn't handle dependencies, metadata, and maintainer scripts as nicely as the native toolchain does.
CodeYeti
17-01-2013, 17:47
Because CPack, though easy, doesn't handle dependencies, metadata, and maintainer scripts as nicely as the native toolchain does.
Alright. I didn't know it didn't have the capability to handle dependencies.
Also, I'm still having that same issue with not finding the C++ includes. <see above>
EDIT:If I'm asking a ton of questions, it's because this is more of a learning experience than a hardcore project for me :D.
EDIT 2: I installed the versions of the packages from your dropbox, and I'm still getting the c++ headers problem. The headers are in the exact same place as they are on my mac, where the whole system works (manual installs, no packages or anything).
Alright. I didn't know it didn't have the capability to handle dependencies.
Also, I'm still having that same issue with not finding the C++ includes. <see above>
Stupid question: do the directories specified by `powerpc-wrs-vxworks-gcc -print-prog-name=cc1plus` -v exist and have contents that make sense?
I don't know why that's not working...
EDIT:If I'm asking a ton of questions, it's because this is more of a learning experience than a hardcore project for me :D.
That's great :). Though I don't see why things can't be hardcore projects and learning experiences at the same time! ;)
CodeYeti
17-01-2013, 18:02
Well there's the problem. It appears to be looking for the includes in /usr/local instead of /usr. Here's the output from your line of bash.
ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-wrs-vxworks/4.8.0/../../../../powerpc-wrs-vxworks/include/c++/4.8.0"
ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-wrs-vxworks/4.8.0/../../../../powerpc-wrs-vxworks/include/c++/4.8.0/powerpc-wrs-vxworks"
ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-wrs-vxworks/4.8.0/../../../../powerpc-wrs-vxworks/include/c++/4.8.0/backward"
ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-wrs-vxworks/4.8.0/../../../../powerpc-wrs-vxworks/sys-include"
ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-wrs-vxworks/4.8.0/../../../../powerpc-wrs-vxworks/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/powerpc-wrs-vxworks/4.8.0/include
/usr/local/lib/gcc/powerpc-wrs-vxworks/4.8.0/include-fixed
End of search list.
This might be due to if finding things in /usr/local/lib that it shouldn't because of remnants of old installed-from-source toolchains. I'll try to get rid of breadcrumbs and report back.
EDIT: I think there's a bug in the wrs-headers-installer package. It doesn't actually remove a bunch of stuff, and I get a warning about the directory not being removed because its not empty. Here's the output.
mcoffin@mlc-debian-i7990x:~/Downloads$ sudo dpkg -P powerpc-wrs-vxworks-binutils powerpc-wrs-vxworks-gcc powerpc-wrs-vxworks-buildscripts wrs-headers-installer
(Reading database ... 120972 files and directories currently installed.)
Removing powerpc-wrs-vxworks-gcc ...
Purging configuration files for powerpc-wrs-vxworks-gcc ...
Removing powerpc-wrs-vxworks-buildscripts ...
dpkg: warning: while removing powerpc-wrs-vxworks-buildscripts, directory '/usr/powerpc-wrs-vxworks/share' not empty so not removed
Removing wrs-headers-installer ...
Purging configuration files for wrs-headers-installer ...
Removing powerpc-wrs-vxworks-binutils ...
dpkg: warning: while removing powerpc-wrs-vxworks-binutils, directory '/usr/powerpc-wrs-vxworks' not empty so not removed
Processing triggers for man-db ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
CodeYeti
17-01-2013, 18:16
Well, after becoming pretty sure that I've removed all the breadcrumbs from having the compiler installed under /usr/local, I tried the process again, now it can't find any of the headers due to looking for them in /usr/local. Heres the new include search paths.
ignoring nonexistent directory "/usr/local/lib/../powerpc-wrs-vxworks/include/c++/4.8.0"
ignoring nonexistent directory "/usr/local/lib/../powerpc-wrs-vxworks/include/c++/4.8.0/powerpc-wrs-vxworks"
ignoring nonexistent directory "/usr/local/lib/../powerpc-wrs-vxworks/include/c++/4.8.0/backward"
ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-wrs-vxworks/4.8.0/include"
ignoring nonexistent directory "/usr/local/lib/gcc/powerpc-wrs-vxworks/4.8.0/include-fixed"
ignoring nonexistent directory "/usr/local/lib/../powerpc-wrs-vxworks/sys-include"
ignoring nonexistent directory "/usr/local/lib/../powerpc-wrs-vxworks/include"
EDIT: Fixed this. I had old binaries in /usr/local/bin that were causing GCC to think that it was installed there.
EDIT 2: Only problem I'm having at the moment is cpack putting wpilib in the wrong spot. I'm trying to use cpack just to learn how to before reverting back to the regular packages. cpack seems to ignore CMAKE_INSTALL_PREFIX.
Thank you for your work. I'll be mirroring the files at http://www.eshsrobotics.com/mirror/frctoolchain.zip
Thank you for your work. I'll definitely be contributing to this project.
I'm mirroring your binaries on our team website http://eshsrobotics.com/mirror/frctoolchain.zip
I'll eventually set up a PPA.
CodeYeti
02-02-2013, 15:47
Hi everybody. Just as an update, I've been dorking around with using lambda functions to define delegate math inline. For an example of the usage of a lambda function on a FIRST robot, take a quick look at the Loader::Loader(Joystick *) constructor in this file:
https://github.com/rmr662/temp-test-robot/blob/master/src/RMRLoader.cpp
Please note that this will only work with C++11.
CodeYeti
15-02-2013, 01:07
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
I've updated my build script to build a toolchain using a gcc snapshot and no patches to anything.
https://bitbucket.org/jmesmon/vxworks-gcc-patches (https://bitbucket.org/jmesmon/vxworks-gcc-patches)
Keep in mind that this does delete quite a few directories, make sure you've read the script before using it.
Some caveats on this build and gcc in general:
I had to disable building of gcov via "inhibit_libc=true", the fixincludes don't work around it's use of open() or mkdir().
Setting WIND_BASE is still necessary (this is rather silly)
I haven't run this on a real robot. The only thing I've test built is here (https://github.com/jmesmon/frc-min)
I have set it to build libstdc++-v3, but I have no idea if that will work with vxworks.
I don't do any extraneous copying or symlinking. Issues with "coreip" are expected. Fixing these need changes to "-isystem" within gcc (coincidentally the same thing that hilariously wants WIND_BASE)
William Kunkel
16-02-2013, 13:44
Hi everybody! I've been trying to get this built on my Gentoo box, but I've run into issues, and googling hasn't turned up anything. It compiles a few things, then I run into this:
/bin/sh: MULTIDIR: command not found
/bin/sh: MULTIDIR: command not found
/bin/sh: MULTIDIR: command not found
In file included from /home/maraschinopanda/alt-gcc/gcc-build/gcc/include-fixed/unistd.h:13:0,
from ../../../gcc-master/libgcc/../gcc/tsystem.h:102,
from ../../../gcc-master/libgcc/libgcc2.c:27:
/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>
^
compilation terminated.
Then the error cascades and make exits error code 2. Unfortunately, I don't know enough about GCC to diagnose the issue. Any pointers?
Please Identify
the version of gcc used
the configure command used
the make command used
William Kunkel
16-02-2013, 14:59
The output of gcc --version is:
gcc (Gentoo 4.5.4 p1.0, pie-0.4.7) 4.5.4
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The configure command was:
../gcc-master/configure --prefix=/usr --target=powerpc-wrs-vxworks --with-gnu-as --with-gnu-ld --with-headers --disable-shared --disable-libssp --disable-multilib --with-float=hard --enable-languages=c,c++ --enable-threads=vxworks --without-gconv --disable-libgomp --disable-nls --disable-libmudflap --with-cpu-PPC603 --disable-symvers
And the make command was just
make -j4
Thanks for the help!
The output of gcc --version is:
Please indicate the version of the gcc source code you are building (not the version of gcc you are using to build it).
You may need to pass the location of the headers to gcc's configure command in "--with-headers" (unless you've copied them in place previously).
This isn't your current issue, but for "make" to work you'll need to do "make -j4 inhibit_libc=true" (--without-gcov doesn't appear to work, adding "inhibit_libc=true" actually prevents gcov from being built).
William Kunkel
16-02-2013, 15:53
I'm sorry, I don't full understand what you're telling me to do. I'm not very familiar with the gcc build process. I've just been following the instructions rbmj posted at the beginning of this thread (although they had several issues which I had to correct). Are there other things I ought to be doing?
What are the contents of gcc-master/gcc/DATESTAMP and gcc-master/gcc/BASE-VER?
the contents of these files gives us a good idea about what version of gcc you are trying to compile
the "gcc-master" portion is taken from the command outputs you have previously posted
Edit: Also, to really help, we need to know the complete steps you've taken in trying to build it (you mention you changed some things in rbmj's instructions).
Edit2: also, I'm only asking you for the version info so I can tell you to use a newer version. If you're not trying to build a recent _snapshot_ of gcc-4.8, failure is likely.
Edit3: FYI, I've used 4.8-20130210 successfully in the build script I posted http://www.chiefdelphi.com/forums/showpost.php?p=1234221&postcount=86
Edit4: Looking back at rbmj's original instructions, he uses an archive of the current vcs version (via the git mirror on github), so it should be the latest version. This just means you probably missed something with the headers. I've found that doing the copy & symlink dance is completely unneeded, and omit it in my build script.
William Kunkel
16-02-2013, 19:37
Sorry it took so long to respond. The sequence of commands I ran (cleaned up a bit without ls's and such) was the following. I added comments to every line I modified.
mkdir gcc-install-tmp
cd gcc-install-tmp
sudo mkdir -p /usr/powerpc-wrs-vxworks/wind_base
sudo mkdir -p /usr/powerpc-wrs-vxworks/include
sudo echo 'export WIND_BASE=/usr/powerpc-wrs-vxworks/wind_base' >> /etc/profile
source /etc/profile
wget https://github.com/mirrors/gcc/archive/master.zip
wget http://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.bz2
wget ftp://ftp.ni.com/pub/devzone/tut/updated_vxworks63gccdist.zip
# The file downloaded from github is called "master.zip",
# I'm not sure why he had gcc-master.zip
unzip master.zip
tar -jxvf binutils-2.22.tar.bz2
unzip updated_vxworks63gccdist.zip
mkdir -p $WIND_BASE/target
sudo cp -R gccdist/WindRiver/vxworks-6.3/host/. $WIND_BASE/host
# I switched these next two lines, because otherwise I'm trying to create
# a link to a file that isn't there yet
sudo cp -R gccdist/WindRiver/vxworks-6.3/target/h/. /usr/powerpc-wrs-vxworks/sys-include
sudo ln -s /usr/powerpc-wrs-vxworks/sys-include $WIND_BASE/target/h
sudo ln -s sys-include/wrn/coreip /usr/powerpc-wrs-vxworks/include
mkdir binutils-build
cd binutils-build
../binutils-2.22/configure --prefix=/usr --target=powerpc-wrs-vxworks --disable-nls
make -j4
sudo make install
cd ..
mkdir gcc-build
cd gcc-build
../gcc-master/configure \
--prefix=/usr \
--target=powerpc-wrs-vxworks \
--with-gnu-as \
--with-gnu-ld \
--with-headers \
--disable-shared \
--disable-libssp \
--disable-multilib \
--with-float=hard \
--enable-languages=c,c++ \
--enable-threads=vxworks \
--without-gconv \
--disable-libgomp \
--disable-nls \
--disable-libmudflap \
--with-cpu-PPC603 \
--disable-symvers
# And this is where it fails
make -j4
The contents of gcc-master/gcc/DATESTAMP is:
20130215
And the contents of gcc-master/gcc/BASE-VER is:
4.8.0
Your GCC is plenty recent (as I belatedly realized).
It's probably something to do with the copying and symlinking sillyness. I haven't set my own install up like that, rather, I let gcc's configure copy $WIND_BASE/target/h to $PREFIX/sys-include.
You could try that
export WIND_BASE=$(realpath -m gccdist/WindRiver/vxworks-6.3)
# configure gcc with an argument to --with-headers
--with-headers="$WIND_BASE/target/h"
Keep in mind that I've not tested anything that is built with the resulting toolchain (as I don't have a cRIO).
Edit: Make sure that you clear out /usr/powerpc-wrs-vxworks (your PREFIX) completely before trying again. Left over directory setups and files can cause issues.
William Kunkel
17-02-2013, 12:59
Alright, I tried your suggestion. It got farther this time but now it's failing with this error:
In file included from /home/maraschinopanda/alt-gcc/gcc-build/gcc/include-fixed/syslimits.h:7:0,
from /home/maraschinopanda/alt-gcc/gcc-build/gcc/include-fixed/limits.h:34,
from ../../../gcc-master/libgcc/libgcc2.c:1731:
/home/maraschinopanda/alt-gcc/gcc-build/gcc/include-fixed/limits.h:168:61: error: no include path in which to search for limits.h
#include_next <limits.h> /* recurse down to the real one */
^
Did you completely remove PREFIX before reattempting the build?
Did you completely remove the build directory before rebuilding?
What was your complete configure line for gcc?
Edit: I tried building the current -9999/head/"master" of gcc via my buildscript and had no issues, I suspect that in your case one of the following is the problem:
--with-headers isn't right, potentially due to WIND_BASE not being set properly
some files/symlinks where left in PREFIX and are messing things up
William Kunkel
17-02-2013, 23:11
I completely removed the PREFIX and build directories. I just pulled from the compressed files I downloaded again, to be safe. The configure line I had was:
../gcc-master/configure \
--prefix=/usr \
--target=powerpc-wrs-vxworks \
--with-gnu-as \
--with-gnu-ld \
--with-headers="$WIND_BASE/target/h" \
--disable-shared \
--disable-libssp \
--disable-multilib \
--with-float=hard \
--enable-languages=c,c++ \
--enable-threads=vxworks \
--without-gconv \
--disable-libgomp \
--disable-nls \
--disable-libmudflap \
--with-cpu-PPC603 \
--disable-symvers
And I had set $WIND_BASE to
$(realpath -m gccdist/WindRiver/vxworks-6.3)
per your post.
I also changed my make command from
make -j4
to
make -j4 inhibit_libc=true
per your earlier suggestion.
The only useful information I have found about this was that it can sometimes be caused by missing glibc, but I do have the most recent version Gentoo considers stable.
Thanks for all the help so far!
Just to be sure, you're letting the $(realpath ... ) bit expand when it is assigned to WIND_BASE, right? Meaning that you aren't using single quotes around it, and `echo $WIND_BASE` gives something like '/home/maraschinopanda/alt-gcc/gccdist/WindRiver/vxworks-6.3'?
Can you check that `ls $WIND_BASE` works from the directory you're calling gcc's configure from?
Also, I recommend not using /usr as your prefix (especially not when testing), as it is actually used by other programs and removing it will break your system. I prefer using ~/x-tools/wrs (I have some shell setup scripts that add all of ~/x-tools/*/bin to my path). Any unused path is fine (an one in your homedir has the benefit of not needing to install with root privileges).
Edit: Note that the glibc you have installed on your system is _not_ going to cause your issue, the compiler for vxworks that you are building does _not_ use glibc at all.
William Kunkel
18-02-2013, 02:49
I didn't think glibc was the problem, but I thought it was worth mentioning. I didn't remove /usr itself, of course, but I did remove all of the changes the build made. However, I can see why it might be better to use another prefix. I did make certain that $WIND_BASE was doing what I expected. I could try recompiling with a temporary prefix.
Hi everybody! I've been trying to get this built on my Gentoo box, but I've run into issues, and googling hasn't turned up anything. It compiles a few things, then I run into this:
Then the error cascades and make exits error code 2. Unfortunately, I don't know enough about GCC to diagnose the issue. Any pointers?
That's an issue with include directories.
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
If you don't set WIND_BASE you'll get the "cannot compute suffix of object files" error (most likely) at configure time.
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).
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.
limits.h is in target/h, not target/h/wrn/coreip , so symlinking in wrn/coreip will not help at all for this error.
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:
/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
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
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:
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?
frcmake (https://github.com/rbmj/powerpc-wrs-vxworks-buildscripts/blob/master/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.
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:
CFLAGS='-mcpu=603 -mstrict-align -mlongcall -DTOOL=gnu' ./configure --host=powerpc-wrs-vxworks --prefix=/usr/powerpc-wrs-vxworks
byteit101
21-02-2013, 18:38
I must say, this is very cool. Has anyone gotten GDB or any debugging working yet?
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:
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.
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.
Can you link to the patch that is going into 4.8.1?
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
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?
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):
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
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:
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
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.
With my setup, I have:
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
Thanks for the help!
William Kunkel
24-02-2013, 20:51
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.
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-installer/blob/master/debian/postinst
wlmeng11
28-02-2013, 00:31
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"):
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
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.
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.
@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?
@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
@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
The complete output of make VERBOSE=1 is as follows:
/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
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.
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:
$ 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
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)
@wlmeng11
yes. See the build script I use, more info in this post back on page 7:
http://www.chiefdelphi.com/forums/showpost.php?p=1234221&postcount=86
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/viewPage/projects.c--11_toochain/wiki/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/viewPage/projects.c--11_toochain/wiki/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
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/viewPage/projects.c--11_toochain/wiki/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/viewPage/projects.c--11_toochain/wiki/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.
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
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:
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
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:
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/projects.c--11_toochain/wiki
AlexBrinister
10-03-2013, 11:53
@MaraschinoPanda
Looks like you're not specifying -std=gnu++11 on the gcc command line
This is one of your compile lines:
/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
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
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
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:
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
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
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
Okay - thank you. I have posted in a Networktables thread. I appreciate your help.
AlexBrinister
10-03-2013, 15:12
@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:
#!/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
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
@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
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
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.
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/commit/393a2d9a041111888152e98f43bd2a05ca432d16
https://github.com/rbmj/wpilib/commit/40234cc6df77f2e37f119ca63af078440561da01
AlexBrinister
12-03-2013, 20:41
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
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
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
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
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.
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...
#!/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
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.
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
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.
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!).
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:
deb http://debian.repo.frc.s3.amazonaws.com wheezy main
The maintainer key may be added using:
# wget -O - http://debian.repo.frc.s3.amazonaws.com/rbmj.gpg.key | apt-key add -
And the packages may be installed using:
# 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 (http://firstforge.wpi.edu/sf/wiki/do/viewPage/projects.c--11_toochain/wiki/BinaryInstall)
For more information on compiling from source, see
this wiki page (http://firstforge.wpi.edu/sf/wiki/do/viewPage/projects.c--11_toochain/wiki/ManualInstall)
For instructions on how to build FRC code using this package the best way, see this wiki page (http://firstforge.wpi.edu/sf/wiki/do/viewPage/projects.c--11_toochain/wiki/UsingCMake).
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
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.
Looks like I forgot to push the last set of packages to the server... The install should work now.
Looks great, thanks!
Doesn't launchpad provide free hosting for packages (via ppas)? Any reason you are using aws instead?
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.
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/viewRelease/projects.c--11_toochain/frs.windows_installers.alpha0
Howto (note that on windows, you need to use mingw32-make):
http://firstforge.wpi.edu/sf/go/wiki1288
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.