|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools |
Rating:
|
Display Modes |
|
#61
|
|||
|
|||
|
Re: Alternate GCC Toolchain
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... |
|
#62
|
|||
|
|||
|
Re: Alternate GCC Toolchain
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: Code:
$ frcmake $SRCDIR -DCMAKE_CXX_FLAGS='-std=c++11 -fpermissive' |
|
#63
|
||||
|
||||
|
Re: Alternate GCC Toolchain
Quote:
|
|
#64
|
|||
|
|||
|
Re: Alternate GCC Toolchain
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. |
|
#65
|
||||
|
||||
|
Re: Alternate GCC Toolchain
Quote:
|
|
#66
|
|||
|
|||
|
Re: Alternate GCC Toolchain
|
|
#67
|
||||
|
||||
|
Re: Alternate GCC Toolchain
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.
Code:
cmake . make && sudo make install Also: should I just switch to the packages, even if I'm planning on actively developing if I find a bug/missing feature? |
|
#68
|
|||
|
|||
|
Re: Alternate GCC Toolchain
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.
|
|
#69
|
||||
|
||||
|
Re: Alternate GCC Toolchain
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? Code:
../../../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
Last edited by CodeYeti : 16-01-2013 at 19:02. |
|
#70
|
||||
|
||||
|
Re: Alternate GCC Toolchain
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 |
|
#71
|
|||
|
|||
|
Re: Alternate GCC Toolchain
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. Last edited by rbmj : 17-01-2013 at 15:30. |
|
#72
|
||||
|
||||
|
Re: Alternate GCC Toolchain
Quote:
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: Code:
limits.h README syslimits.h Code:
-Wno-write-strings 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. Last edited by CodeYeti : 17-01-2013 at 00:51. Reason: edit #4 |
|
#73
|
||||||
|
||||||
|
Re: Alternate GCC Toolchain
Quote:
Well, if it's a static const you can: Code:
//foo.h
class foo {
static const float bar;
};
//foo.cpp
#include "foo.h"
const float foo::bar = 1.0;
Quote:
Quote:
Quote:
Quote:
![]() Quote:
|
|
#74
|
||||
|
||||
|
Re: Alternate GCC Toolchain
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. Last edited by CodeYeti : 17-01-2013 at 15:20. |
|
#75
|
|||
|
|||
|
Re: Alternate GCC Toolchain
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: Code:
# 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 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... |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|