Code failing to load (Undefined symbol)

Technical C/C++
1

I recently ran into a very weird… bug? glitch? Here’s the rundown:

  1. When trying to deploy this code: https://bitbucket.org/teammetalcow/2013offseason/src it deploys 100% okay, but after reboot, we get a “No Robot Code” on the DS, as well as a message saying it failed to load, with a NetConsole message that there was an “Undefined reference to _ZN11VectorDrive3kPyE.”. I had edited the file (Subsystems/VectorDrive.h) which has the VectorDrive class in it, but only added a minus sign in line 140. I’m confused as to how that could cause this error.

  2. Any other code/program works fine.

  3. Reverting back to without the minus does not change anything. (I think that’s all I changed.)

  4. A clean build does not change anything.

  5. Creating a new project and copying over source does not change anything.

  6. Formatting the cRIO does not change anything.

  7. Deploying straight to cRIO/Over Ethernet/over WiFi does not change anything.

I’m extremely baffled. I would be overhauling the code I changed tomorrow anyways, I will see if that fixes my problems. But this is an extremely confusing problem. Has anyone ever had such an issue before? :confused:

EDIT:
Fixed it by overhauling the code that was changed.
I’m still baffled over this, though.

2

The probable cause is that the compiler in windriver for vxWorks is very permissive of function names (and class names?) at compile time, and doesn’t give a warning or error when it doesn’t see a function you are referring to; instead it assumes that the function will be available at runtime on the cRio.

The result is that if you call functions (not methods of classes, which IIRC do get checked, since they are scope limited, but don’t quote me on that), but have spelling/case errors, the compiler assumes it is an intentional reference to something it doesn’t know about. In other cases, calling general library functions (such as itof) can cause this, since the library isn’t on the cRio.

When you encounter this from an innocuous change, look at what has changed very carefully, and look at what may have changed in your runtime code path as the result of the change, since the problem could be in code you’ve had for a while, but don’t typically call.

3

Theres a few different methods for tracking this down in the following thread: http://www.chiefdelphi.com/forums/showthread.php?t=114080