|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools |
Rating:
|
Display Modes |
|
#31
|
|||
|
|||
|
Re: Alternate GCC Toolchain
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."
Code:
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$
|
|
#32
|
|||
|
|||
|
Re: Alternate GCC Toolchain
Quote:
Quote:
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. |
|
#33
|
|||
|
|||
|
Re: Alternate GCC Toolchain
Quote:
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. Last edited by agartner01 : 12-01-2013 at 00:26. |
|
#34
|
||||
|
||||
|
Re: Alternate GCC Toolchain
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:
Code:
Warning: module 0xe780b8 (FRC_UserProgram.out) holds reference to undefined symbol _ZN14IterativeRobot16TeleopContinuoutEv <more errors similar to the one above> ...FRC_UserProgram failed to load. |
|
#35
|
||||
|
||||
|
Re: Alternate GCC Toolchain
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:
Code:
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. |
|
#36
|
|||
|
|||
|
Re: Alternate GCC Toolchain
Quote:
|
|
#37
|
||||
|
||||
|
Re: Alternate GCC Toolchain
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. Last edited by CodeYeti : 12-01-2013 at 17:15. |
|
#38
|
|||
|
|||
|
Re: Alternate GCC Toolchain
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...
|
|
#39
|
||||
|
||||
|
Re: Alternate GCC Toolchain
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. |
|
#40
|
|||
|
|||
|
Re: Alternate GCC Toolchain
Quote:
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. |
|
#41
|
||||
|
||||
|
Re: Alternate GCC Toolchain
Quote:
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 |
|
#42
|
|||
|
|||
|
Re: Alternate GCC Toolchain
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.
|
|
#43
|
|||
|
|||
|
Re: Alternate GCC Toolchain
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: Code:
extern "C" {
void _start() {
//output an error message?
}
}
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. |
|
#44
|
||||
|
||||
|
Re: Alternate GCC Toolchain
Quote:
|
|
#45
|
|||
|
|||
|
Re: Alternate GCC Toolchain
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.
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|