Chief Delphi
Page 3 of 11 < 12 3 45678910 > Last »
Show 100 post(s) from this thread on one page

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Alternate GCC Toolchain (http://www.chiefdelphi.com/forums/showthread.php?t=109385)

agartner01 11-01-2013 22:17
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$

rbmj 11-01-2013 23:29
Re: Alternate GCC Toolchain
 
Quote:
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.
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?

Quote:
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$
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
Re: Alternate GCC Toolchain
 
4 Attachment(s)
Quote:
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?
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
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.
Any help is appreciated. Thanks!

CodeYeti 12-01-2013 15:30
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.
Thanks in advance for the help and sorry for the double post.

agartner01 12-01-2013 15:55
Re: Alternate GCC Toolchain
 
1 Attachment(s)
Quote:
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:
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.
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
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.

rbmj 12-01-2013 20:39
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...

CodeYeti 12-01-2013 20:59
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.

rbmj 12-01-2013 21:14
Re: Alternate GCC Toolchain
 
Quote:
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.
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
Re: Alternate GCC Toolchain
 
Quote:
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.
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
Re: Alternate GCC Toolchain
 
Quote:
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...
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.

rbmj 13-01-2013 00:36
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?
}
}
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
Re: Alternate GCC Toolchain
 
Quote:
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:
Code:
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
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.


All times are GMT -5. The time now is 20:08.
Page 3 of 11 < 12 3 45678910 > Last »
Show 100 post(s) from this thread on one page

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi