![]() |
Re: Alternate GCC Toolchain
Quote:
|
Re: Alternate GCC Toolchain
Quote:
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. |
Re: Alternate GCC Toolchain
limits.h is in target/h, not target/h/wrn/coreip , so symlinking in wrn/coreip will not help at all for this error.
|
Re: Alternate GCC Toolchain
Quote:
Quote:
|
Re: Alternate GCC Toolchain
Hi!
I built this successfully on Arch Linux x64 with the instruction in the OP save for the unzip command having the wrong name (should be "unzip master.zip" ) and building gcc-build with "make -j4 inhibit_libc=true". I haven't tested on a robot yet, but successfully compiled jmesmon's test program. https://github.com/jmesmon/frc-min I will try to make a PKGBUILD for this in the Arch Linux AUR if I can. |
Re: Alternate GCC Toolchain
I've successfully compiled GCC and friends, and can use frcmake to compile robot code successfully. However, I can't seem to figure out how to compile another project that uses autotools (./configure), it always fails on trying to find pthreads, with the last screenfull saying "checking for pthread_***... no" and ending with 'configure: WARNING: "Don't know how to find pthread library on your system -- thread support disabled"'
I can however compile using frcmake pthread stuff, so I think its just a matter of a missing path/configuration here is my current command: Code:
LDFLAGS=-L/usr/powerpc-wrs-vxworks/lib/ CFLAGS='-I/usr/powerpc-wrs-vxworks/include/:/usr/powerpc-wrs-vxworks/sys-include/ -mcpu=603 -mstrict-align -mlongcall -nostdlib -ansi -Wall -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL' PATH=/usr/powerpc-wrs-vxworks/bin:$PATH ./configure --host=powerpc-wrs-vxworksUPDATE: 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? |
Re: Alternate GCC Toolchain
frcmake link for those (like me) who end up googling around.
Don't add the -L to LDFLAGS and that -I to CFLAGS : those are the defaults which the compiler will already use. The other CFLAGS _may_ be needed. Specifically the -m* options are probably needed, the -D* options depend on how funky vxworks' headers are, and the others could be omitted based on preference. I don't _think_ '-nostdlib' is needed, though I might be wrong on that. I tend to set PATH globally (in bashrc or otherwise), but setting it there is valid. Actually, instead of setting path, passing --prefix=/usr/powerpc-wrs-vxworks (in your case) probably makes more sense. Essentially, I'd try the following and then tweak it when it doesn't work because someone screwed up their build system. Code:
CFLAGS='-mcpu=603 -mstrict-align -mlongcall -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL' ./configure --host=powerpc-wrs-vxworks --prefix=/usr/powerpc-wrs-vxworksEdit: Digging a bit more, _WRS_KERNEL_, TOOL_FAMILY, and CPU are defined properly without the need for -D*. (CPU is PPC604 unless -mcpu=603 is passed, which is strange given the --with-cpu-PPC603 configure option was used) Potentially bringing it down to: Code:
CFLAGS='-mcpu=603 -mstrict-align -mlongcall -DTOOL=gnu' ./configure --host=powerpc-wrs-vxworks --prefix=/usr/powerpc-wrs-vxworks |
Re: Alternate GCC Toolchain
I must say, this is very cool. Has anyone gotten GDB or any debugging working yet?
|
Re: Alternate GCC Toolchain
Quote:
Here's an explanation of what the cmake-based buildchain does to link your robot code module: 1) links as normal, without any libraries 2) statically links in the standard library 3) runs a script called "munch" 4) links the output of (2) with the output of (3) 5) runs a script called stripsyms Note: The default build toolchain does (1) and (3) and then links them together An explanation for munch: this finds all of the constructors and destructors of global or static objects in the binary and creates a special vxworks data structure that will allow vxworks to run these. Also, with the new toolchain, we link the necessary standard libraries statically. In the default implementation, the standard libraries is linked dynamically, and vxworks already loads a copy of the standard library into memory, so your code sees these symbols and works. However, because of any incompatibilities between the old and new versions at a binary level, we include our own copy. This is where stripsyms comes in Stripsyms is necessary in order to localize (think hide) our copy of the vxworks standard library from the rest of the system. This way, when vxworks loads our code, it doesn't load the symbols from our copy of the standard library into memory, so the rest of the OS can pretend that our copy doesn't exist. This manual linking and processing is the reason why '-nostdlib' is necessary - don't want to prematurely link in something twice. It's not the most elegant way to do things, but it's the way that worked for me. At the end of the 2012 season I spent quite a bit of time fiddling with this, and it took a *long* time before I could finally get everything to cooperate and run successfully. Thus, any third-party code might require some special coaxing before it'll work on a real robot :( Also, I am relying on the community to test this project. It still hasn't been vigorously tested in a production environment using all the features and possible corner cases. Right now I am not a good maintainer as my time is severely limited and I do not have access to a cRIO to run code on :( I'm hoping that with a bit of testing, once GCC 4.8 is released this can be sufficiently mature to offer to teams as a stable alternative to the official toolchains and the UCPP project (a great project, but with different aims) for real robot code (not just to play with). Though, if anyone *is* using this on their robot, I'm eager to hear how it turns out! Also, as a bit of good news, my final patch for GCC got accepted (though for 4.8.1, not 4.8.0 :/). There's still no real support for any other languages (fortran is the closest I think, but when I tried to make it gcc's build system acts strangely). Don't worry though, that patch relates to a corner case in thread specific data, so for 99% of people 4.8.0 should be safe. Quote:
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. |
Re: Alternate GCC Toolchain
Can you link to the patch that is going into 4.8.1?
|
Re: Alternate GCC Toolchain
It's uber trivial (has to do with neglecting to pass an argument to a function, that's it), but here you go: http://article.gmane.org/gmane.comp.gcc.patches/281127/
|
Re: Alternate GCC Toolchain
Alright, I got it to compile, but I think I might have issues. The cmake scripts depend on "/usr/powerpc-wrs-vxworks/lib/libstdc++.a" and "/usr/powerpc-wrs-vxworks/lib/libsupc++.a" existing, but post-install, they are nowhere to be found. Did I miss a step? Or are they added by the debian package that I cannot use?
|
Re: Alternate GCC Toolchain
So, it turns out I (or we) haven't actually been building with libstdc++-v3 enabled, because the flag is "--enable-libstdcxx" not "--enable-libstdc++-v3". As I'm pretty sure it was being built with 4.7.x, my guess is that the flag got changed in 4.8.
In short, this is my current gcc configure (I've also fiddled with static & shared, you could leave those as they were previously set if there are issues in practice): Code:
FLAGS_FOR_TARGET="-isystem $PREFIX/powerpc-wrs-vxworks/sys-include/wrn/coreip" |
Re: Alternate GCC Toolchain
I finally figured out what was wrong with the symlinking! In the second step, we make the directory "/usr/powerpc-wrs-vxworks/include". So, when we try to make a symlink with the same name later:
Code:
ln -s sys-include/wrn/coreip /usr/powerpc-wrs-vxworks/include |
Re: Alternate GCC Toolchain
Does anyone have an example of a CMakeLists.txt file for a robot project? I'm a little lost on what to do, and being able to see one would help greatly.
|
Re: Alternate GCC Toolchain
With my setup, I have:
Code:
cmake_minimum_required(VERSION 2.8) |
Re: Alternate GCC Toolchain
Thanks for the help!
|
Re: Alternate GCC Toolchain
Alright, one final thing. I seem to be missing "/usr/powerpc-wrs-vxworks/share/ldscripts/dkm.ld". Where is this supposed to come from? I didn't see it in any of the git repos and it didn't look like it was generated by any of the CMakeLists files. I'm probably missing something obvious.
|
Re: Alternate GCC Toolchain
It's generated by my wrs-headers-installer install script. You can see it near the bottom of that script. Link: https://github.com/rbmj/wrs-headers-...ebian/postinst
|
Re: Alternate GCC Toolchain
Has anyone been able to build this with Ubuntu 12.04? (x86_64)
I was able to build it fine on both of my Arch Linux machines, but no luck on Ubuntu. Here is one of the errors while compiling gcc-build (with "make -j4 inhibit_libc=true"): Quote:
|
Re: Alternate GCC Toolchain
Does anyone know if there's support for C++11's new math functions, namely copysign()? It wasn't working for me, but that could just be on my end.
|
Re: Alternate GCC Toolchain
Quote:
|
Re: Alternate GCC Toolchain
@wlmeng11 I've just built it successfully in a Ubuntu 12.04 64.
The "--64" indicates 64 bit, and I'm pretty sure it should be running /user/powerpc-wrs-vxworks/bin/powerpc-wrs-vxworks-as not /user/powerpc-wrs-vxworks/bin/as . Are you sure you passed --target to both binutils & gcc's configure? |
Re: Alternate GCC Toolchain
Quote:
Binutils is fine - as isn't supposed to take a --64 argument AFAIK. Can you post your config.log? |
Re: Alternate GCC Toolchain
Quote:
Which version of GCC are you using and where did you get it? (official repos, PPA, or source) |
Re: Alternate GCC Toolchain
The complete output of make VERBOSE=1 is as follows:
Quote:
|
Re: Alternate GCC Toolchain
I've been building either the gcc-master tarballs from github (ie: latest snapshot), or using the date marked snapshots from the gcc mirrors.
ie: all source, all upstream. |
Re: Alternate GCC Toolchain
Quote:
Code:
$ frcmake $SRCDIR -DCMAKE_CXX_FLAGS='-std=c++11 -fpermissive' |
Quote:
|
Re: Alternate GCC Toolchain
@wlmeng11
yes. See the build script I use, more info in this post back on page 7: http://www.chiefdelphi.com/forums/sh...1&postcount=86 |
Re: Alternate GCC Toolchain
UPDATE:
I've figured out how to get the repository to work, and I'm in the free tier for amazon s3. Thus, here's the link to a new FirstForge wiki page on how to set it up: http://firstforge.wpi.edu/sf/wiki/do.../BinaryInstall Currently, I only have packages for debian wheezy. I don't know if they will be binary-compatible with Ubuntu. The only binary library dependencies are libc and zlib, which are both pretty good with compatibility, bu you never know... There's also instructions on how to build the packages here: http://firstforge.wpi.edu/sf/wiki/do.../ManualInstall I'll be putting more instructions on how to compile manually from source (for other distributions) on that last page. Hopefully I should finish updating soon! |
Quote:
The PPA worked for me on Ubuntu 12.04. |
Re: Alternate GCC Toolchain
The new required C++ update to WPILib has been incorporated into the git repo of WPILib and the builds have been uploaded. Let me know if you have any issues. For anyone using the repo, a standard aptitude update && aptitude upgrade should do the trick.
As always, let me know of any issues that arise. |
Re: Alternate GCC Toolchain
I made a PKGBUILD for the 64-bit version of this toolchain. It is available on the AUR. If you have an AUR package installer (like yaourt), you can install it by simply doing:
Code:
yaourt -S vxworks-gcc-toolchain-binAlex Brinister |
Re: Alternate GCC Toolchain
Quote:
http://firstforge.wpi.edu/sf/go/proj..._toochain/wiki |
Re: Alternate GCC Toolchain
@MaraschinoPanda
Looks like you're not specifying -std=gnu++11 on the gcc command line This is one of your compile lines: Code:
/usr/local/bin/powerpc-wrs-vxworks-g++ -c /home/maraschinopanda/src/422-robot-2013/Commands/CheesyDrive.cpp -o CMakeFiles/bin/422-robot-2013.dir/Commands/CheesyDrive.cpp.obj -isystem /usr/local/powerpc-wrs-vxworks/include/WPILib -mcpu=603 -mstrict-align -mlongcall -nostdlib -Wall -DCPU=PPC603 -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNELCode:
CXX_FLAGS="'-std=gnu++11'"This should fix your problem. Also, I would advise not installing in local if you're using a package manager. Install to /usr. Alex Brinister |
Re: Alternate GCC Toolchain
I'm not sure if this is the correct thread to ask this question, but my team is having issues starting a script automatically on our Odroid that is running Ubuntu. Can anyone give them some pointers?
Thank you! |
Re: Alternate GCC Toolchain
What kind of script is it? When do you want it to start?
If you want it to start on start-up, you can make a rc.local file in /etc/init.d. Then, you should do the following: Code:
sudo ln -s /etc/init.d/rc.local /etc/rc<default runlevel number>.d/S99zlocalAlex Brinister |
Re: Alternate GCC Toolchain
Okay - they did that with a cron job using @reboot and the location of the pythin and the location of the script. The problem seems to be with network tables. The Odroid is coming up before the cRio and when the Odroid tries to connect with Network Tables on the cRio before it's up, the cRio never boots. They were getting around this problem earlier by adding a wait before they connect to the Network Tables, but that isn't going to work for autonomous mode. Is there a way to check Network Tables to see if they are running?
|
Re: Alternate GCC Toolchain
I think you should start a new thread concerning this as your problem is not related to this thread. Also, I'm not familiar with NetworkTables. I assume you are using this for vision processing. Our team uses C++ and we also just have our own server and client running on an Intel NUC and the cRIO, respectively.
Alex Brinister |
Re: Alternate GCC Toolchain
Okay - thank you. I have posted in a Networktables thread. I appreciate your help.
|
Re: Alternate GCC Toolchain
@rbmj
From the frc-buildscripts repo, where do the powerpc-wrs-vxworks-* binaries go? /usr/powerpc-wrs-vxworks/bin or /usr/bin? Also, I use a different frcmake in my package. Mine looks like this: Code:
#!/bin/bashAlex Brinister |
Re: Alternate GCC Toolchain
Quote:
|
Re: Alternate GCC Toolchain
Quote:
/usr/bin/powerpc-wrs-vxworks-gcc and /usr/powerpc-wrs-vxworks/bin/gcc are symlinked to each other |
Re: Alternate GCC Toolchain
Have the issues remedied in the new mandatory update for C++ been addressed in rbmj's version of WPILib? Or were they even there to begin with?
|
Re: Alternate GCC Toolchain
Quote:
Quote:
https://github.com/rbmj/wpilib/commi...f078440561da01 |
Re: Alternate GCC Toolchain
I wanted to ask if we should have a specific version of GCC/binutils that we use for these builds. I'm using binutils 2.23.1 and GCC-HEAD for my builds. Should I revert to using binutils 2.22?
Alex Brinister |
Re: Alternate GCC Toolchain
Why would you choose to build an old version of binutils if a newer released version exists? (In other words, I'm in favor of 2.23.1).
|
Re: Alternate GCC Toolchain
Because I'm pretty sure Ubuntu uses 2.22 as the default. Arch has been on 2.23 for a while so that's why I'm asking.
Alex Brinister |
Re: Alternate GCC Toolchain
Quote:
Going through and C++'ing WPILib sounds like something I'm going to do over the summer lol. Alex Brinster |
Re: Alternate GCC Toolchain
Quote:
Quote:
One of the things that's an issue with WPILib in C++11 mode is that with the new constexpr feature, GCC has decided to be more strict about floating point constants being initialized in header files (which is technically not allowed by the standard but has been allowed by GCC for some time). You'll have to make those floating point constants declarations and define them in a .cpp file *or* use a compile-time #ifdef on __cplusplus to use either const or constexpr depending on the standards version. If I recall correctly, this is the reasoning behind my earlier advice to use -fpermissive when compiling with -std=c++11. I don't believe that changing to gnu++11 solved the problem - I think it had to be the evil fpermissive... Quote:
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 ;-) |
Re: Alternate GCC Toolchain
Quote:
Quote:
Also, I integrated GDB into my latest release. I'm still not quite sure how the Ruby thing works though... Alex Brinister |
Re: Alternate GCC Toolchain
Quote:
|
Re: Alternate GCC Toolchain
Quote:
|
Re: Alternate GCC Toolchain
ANNOUNCEMENT
I'm happy to announce that I have built packages for debian testing (should also work on ubuntu) which are available on the apt repo. i686 and amd64 packages are available. No other architectures are supported by this binary repo (though feel free to make your own if you really want to run this on your RPi). Note: Because of some naming changes if you installed my earlier binary packages you MUST uninstall everything *except* wrs-headers-installer before you can install the new packages. An aptitude upgrade will NOT actually upgrade your packages, and may break things! The /etc/apt/sources.list line is: Code:
deb http://debian.repo.frc.s3.amazonaws.com wheezy mainCode:
# wget -O - http://debian.repo.frc.s3.amazonaws.com/rbmj.gpg.key | apt-key add -Code:
# aptitude updateThe wiki's instructions are also updated for 4.8.0 and no longer require running a development version of GCC. For more information on binaries, see this wiki page For more information on compiling from source, see this wiki page For instructions on how to build FRC code using this package the best way, see this wiki page. |
Re: Alternate GCC Toolchain
Quote:
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 |
Re: Alternate GCC Toolchain
Quote:
|
Re: Alternate GCC Toolchain
Quote:
|
Re: Alternate GCC Toolchain
Doesn't launchpad provide free hosting for packages (via ppas)? Any reason you are using aws instead?
|
Re: Alternate GCC Toolchain
Quote:
|
Re: Alternate GCC Toolchain
Hello Everyone,
I've released some alpha windows binaries. These are self-contained windows installer files. Features:
Basically, it contains everything that you need in order to build FRC code. Release Notes C++11 mode is not enabled by default - in order to enable it you need to pass -DCMAKE_CXX_FLAGS=-std=gnu++11 (or c++11) when you invoke frcmake As I do not have a cRIO I am unable to test if this code actually works on a Robot, and am looking for volunteers willing to stress test it to make sure that everything actually works. I am also very interested in people looking to test C++11 features - I highly recommend looking at std::thread, as it promises to make threading much easier. The installer currently creates registry keys rooted in HKLM and modifies system environment variables (it's safe, I promise), so you will need to have administrator access to install. Links Download: http://firstforge.wpi.edu/sf/frs/do/...tallers.alpha0 Howto (note that on windows, you need to use mingw32-make): http://firstforge.wpi.edu/sf/go/wiki1288 |
| All times are GMT -5. The time now is 01:33. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi