Go to Post One career isn't really more prestigious than another; not in and of itself. More than anything it depends on what you do with it. - Matt Leese [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rating: Thread Rating: 6 votes, 5.00 average. Display Modes
  #31   Spotlight this post!  
Unread 11-01-2013, 22:17
agartner01 agartner01 is offline
Captain + Control Sys & Design
FRC #4174
Team Role: Engineer
 
Join Date: Feb 2012
Rookie Year: 2012
Location: Hector MN
Posts: 109
agartner01 is an unknown quantity at this point
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   Spotlight this post!  
Unread 11-01-2013, 23:29
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

Quote:
Originally Posted by agartner01 View Post
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.
  #33   Spotlight this post!  
Unread 11-01-2013, 23:52
agartner01 agartner01 is offline
Captain + Control Sys & Design
FRC #4174
Team Role: Engineer
 
Join Date: Feb 2012
Rookie Year: 2012
Location: Hector MN
Posts: 109
agartner01 is an unknown quantity at this point
Re: Alternate GCC Toolchain

Quote:
Originally Posted by rbmj View Post
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.
Attached Files
File Type: txt WPILibConfig.txt (241 Bytes, 6 views)
File Type: txt WPILibConfigVersion.txt (317 Bytes, 3 views)
File Type: txt build.txt (2.6 KB, 2 views)
File Type: txt VMerror.txt (859 Bytes, 8 views)

Last edited by agartner01 : 12-01-2013 at 00:26.
  #34   Spotlight this post!  
Unread 12-01-2013, 15:11
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
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!
  #35   Spotlight this post!  
Unread 12-01-2013, 15:30
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
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.
  #36   Spotlight this post!  
Unread 12-01-2013, 15:55
agartner01 agartner01 is offline
Captain + Control Sys & Design
FRC #4174
Team Role: Engineer
 
Join Date: Feb 2012
Rookie Year: 2012
Location: Hector MN
Posts: 109
agartner01 is an unknown quantity at this point
Re: Alternate GCC Toolchain

Quote:
Originally Posted by CodeYeti View Post
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.
Attached Files
File Type: txt netconsole.txt (1.6 KB, 7 views)
  #37   Spotlight this post!  
Unread 12-01-2013, 16:09
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
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   Spotlight this post!  
Unread 12-01-2013, 20:39
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
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   Spotlight this post!  
Unread 12-01-2013, 20:59
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
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   Spotlight this post!  
Unread 12-01-2013, 21:14
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

Quote:
Originally Posted by CodeYeti View Post
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.
  #41   Spotlight this post!  
Unread 12-01-2013, 21:40
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
Re: Alternate GCC Toolchain

Quote:
Originally Posted by rbmj View Post
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
  #42   Spotlight this post!  
Unread 12-01-2013, 21:52
agartner01 agartner01 is offline
Captain + Control Sys & Design
FRC #4174
Team Role: Engineer
 
Join Date: Feb 2012
Rookie Year: 2012
Location: Hector MN
Posts: 109
agartner01 is an unknown quantity at this point
Re: Alternate GCC Toolchain

Quote:
Originally Posted by rbmj View Post
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.
  #43   Spotlight this post!  
Unread 13-01-2013, 00:36
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
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.
  #44   Spotlight this post!  
Unread 13-01-2013, 00:45
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
Re: Alternate GCC Toolchain

Quote:
Originally Posted by rbmj View Post
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?
  #45   Spotlight this post!  
Unread 13-01-2013, 00:48
agartner01 agartner01 is offline
Captain + Control Sys & Design
FRC #4174
Team Role: Engineer
 
Join Date: Feb 2012
Rookie Year: 2012
Location: Hector MN
Posts: 109
agartner01 is an unknown quantity at this point
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.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 19:18.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


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