Originally Posted by rbmj (Post 1192704)

Lobby FIRST/WRS/NI to use a compiler that *isn't* ten years old!

Originally Posted by ebarker (Post 1192724)

Why ? Having a C compiler that is ten years old should be solid, reliable, and mature.

Originally Posted by agartner01 (Post 1192727)

Why doesn't everyone just use 6 wheel tank drive, which is arguably more solid and reliable?

Originally Posted by ebarker (Post 1192724)

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

Originally Posted by ebarker (Post 1192724)

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

Originally Posted by agartner01 (Post 1192844)

Checked it again. Still not able to compile. Heres what I get:
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.

Originally Posted by rbmj (Post 1192848)

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.

Originally Posted by agartner01 (Post 1192853)

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:

Originally Posted by rbmj (Post 1161874)

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.

Originally Posted by agartner01 (Post 1192982)

Robot code build completes but gives this error:
When I deploy, I get nothing but "relocation value does not fit in 24 bits"

Originally Posted by CodeYeti (Post 1193076)

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.

At least from what I've read of your problem, that should do the trick.

Originally Posted by CodeYeti (Post 1193076)

Originally Posted by ebarker (Post 1192839)

What I'm curious in learning is why so much embedded C still uses the 3.4.4 version, not the 4.xx series of gcc. That said, what are the risks of using 4.x versus 3.4.4 in an embedded system.

Originally Posted by CodeYeti (Post 1193076)

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.

Originally Posted by CodeYeti (Post 1210908)

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

Originally Posted by danopia (Post 1212703)

I have a high-bandwidth web server that can host any arbitrary files, if you tell me how to set up a repo I can do that for you. (I assume that mirroring just the binaries alone is not enough?)

Originally Posted by agartner01 (Post 1213377)

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.

---

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$

---

Originally Posted by rbmj (Post 1213438)

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?

Originally Posted by CodeYeti (Post 1213736)

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:
Thanks in advance for the help and sorry for the double post.

Originally Posted by CodeYeti (Post 1213953)

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.

Originally Posted by rbmj (Post 1213966)

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.

Originally Posted by rbmj (Post 1213935)

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

Originally Posted by rbmj (Post 1214130)

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

Originally Posted by agartner01 (Post 1214144)

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.

Originally Posted by CodeYeti (Post 1214157)

I can't really sleep so I'm starting to do the binary searching. Do you have a cRIO with you now or no?

Originally Posted by agartner01 (Post 1214159)

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.

Originally Posted by CodeYeti (Post 1214165)

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?

Originally Posted by rbmj (Post 1214293)

OK, I can confirm that it's a flag issue, not a compiler issue. Now just to determine which one...

Originally Posted by rbmj (Post 1214421)

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:

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.

Originally Posted by agartner01 (Post 1214516)

I started a new project and things worked just fine...

Originally Posted by rbmj (Post 1215674)

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:

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

Originally Posted by rbmj (Post 1215900)

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.

Originally Posted by rbmj (Post 1216862)

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 [il]debuild -us -uc[/il]. 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 [il]-e WIND_BASE[/il] 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.

Originally Posted by CodeYeti (Post 1217005)

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.

---

limits.h
README
syslimits.h

---

---

-Wno-write-strings

---

Originally Posted by rbmj (Post 1217350)

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:

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

Originally Posted by CodeYeti (Post 1217419)

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.

Originally Posted by rbmj (Post 1217459)

Because CPack, though easy, doesn't handle dependencies, metadata, and maintainer scripts as nicely as the native toolchain does.

Originally Posted by CodeYeti (Post 1217463)

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>

Originally Posted by MaraschinoPanda (Post 1234413)

The output of gcc --version is:

Originally Posted by MaraschinoPanda (Post 1234369)

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?