Yet another update to C++

[BradAMiller]

There is a compiler bug that was causing some users to see the symbol: kLineLength to show up as undefined when using the DriverStationLCD classes. A new update has been posted that fixes this and is only necessary if you are using that class. It can be found here:

http://first.wpi.edu/FRC/frccupdates.html

Please report any problems with this update.

[heydowns]

There is a compiler bug that was causing some users to see the symbol: kLineLength to show up as undefined when using the DriverStationLCD classes. A new update has been posted that fixes this and is only necessary if you are using that class. It can be found here:

http://first.wpi.edu/FRC/frccupdates.html

Please report any problems with this update.

Brad,

With this update (02-08), we are having problems using the AxisCamera class. We have updated to the new header name (AxisCamera2010.h -> AxisCamera.h) and changed the function names as appropriate for the newly renamed functions (so, IsFreshImage() for example, rather than the old freshImage()).

Our robot code compiles fine, but at runtime Windriver reports that the following symbols are unresolved:

AxisCamera::GetInstance()
AxisCamera::GetImage()
AxisCamera::IsFreshImage()


We also get this with a newly created 2010 Image Demo example.

Looking at the installed WPIlib.a with a 02-08 date, it does not appear that these symbols are actually present in the library.

Is anyone else experiencing these issues?

[Hugh Meyer]

Hi Brad,
The update fixed the kLineLength problem. Now we are seeing the exact same three messages that heydowns is reporting. We commented out all of the camera code to get it to compile, but we will need that camera code.

[heydowns]

Great. Glad it isn't just us having the problem.

Here's a WPIlib.a I built from current WPIlib svn (should be very close to the one used for the release, considering it was a day or two ago). It works for us here. Use (at your own risk!) until WPI can put out an update.

To use, unzip and copy into C:\WindRiver\vxworks-6.3\target\lib
You may want to back up the original WPIlib.a first.

[sunit]

There is a compiler bug that was causing some users to see the symbol: kLineLength to show up as undefined when using the DriverStationLCD classes. A new update has been posted that fixes this and is only necessary if you are using that class. It can be found here:

http://first.wpi.edu/FRC/frccupdates.html

Please report any problems with this update.

This is causing Camera Code to not work. "reference to undefined symbol" errors.

- Sunit

[sunit]

Great. Glad it isn't just us having the problem.

Here's a WPIlib.a I built from current WPIlib svn (should be very close to the one used for the release, considering it was a day or two ago). It works for us here. Use (at your own risk!) until WPI can put out an update.

To use, unzip and copy into C:\WindRiver\vxworks-6.3\target\lib
You may want to back up the original WPIlib.a first.

This version brings back the _ZN16DriverStationLCD11kLineLengthE error.

- Sunit

[BotnEyedJoe]

It looked to me like the WPILib.a in the 4.2 update (which has the corrected DriverStationLCD) has a wrong AxisCamera.o module in it. Looking at the WPILib source, there are normally two variants of AxisCamera.cpp, one in the Vision folder, and one in the Vision2009 folder.

It looks like the Vision2009 version was incorporated into the 4.2 library, twice, and the Vision folder version was not incorporated at all. Could someone else who has compiled WPILib, or is adept at examining its contents, confirm this please, in case I am just crazy? Thanks...

What we did for our own team was, take the (Vision-version) AxisCamera.o from the 4.1 update, and replace the AxisCamera.o entries in the 4.2 WPILib.a with it [We are not using the Vision2009 interfaces at all, so I don't care to have them confuse me.] So we have the camera and the DriverStationLCD both working, because we have the corrected DriverStationLCD from 4.2 combined with the working (2010 variant) AxisCamera, all in the same WPILib.a!

I'm not suggesting this as a solution for teams to follow. I'm only providing this information in an attempt to help find a permanent and more manageable solution.

[heydowns]

This version brings back the _ZN16DriverStationLCD11kLineLengthE error.

- Sunit

Sorry about that. We are not using the DriverStationLCD functionality so I didn't check this - I checked the WPILib svn and it doesn't look like any fixes were checked in for this so I tried my own fix.
I don't have a cRIO to check it on, but the symbols in this one look correct. If someone who uses DriverStationLCD and the camera wants to give it a shot, feel free. Again, use at your own risk as workaround until WPI can put out a fix.

[dcherba]

We have the same type of problems as many of you have describe above. After careful examination of the WPILib in the target directory and the WPILib at the same level as the workspace they do not match. The latest update removed all the .cpp files but did not fix some of the .h files. For example one WPILib.h loads the old AxisCamera and the otherone does not. So if you add the AxisCamera2010 then the compiler reports that you are redifining the AxisCamera.

What does it take to get a correct and consistent set of directories that allows for a creation of a camera object that can feed the PCVideoService.

1. What include, cpp, and o files in what directories
2. What lines of code in the constructor are needed

I would gladly take a long list and check them by hand and copies files manually rather than load another update that just complicates it more.

The example programs don't compile correctly so they are of limited use.

The lack of proper dependency trees is wasting a lot of people time when 6 weeks is already short enough.

Dave Cherba mentor
Rookie team 3234

[rforgaard]

I just want to confirm what others are saying below: The current WPILib 4.2 release for C++, posted to WPI's FRC updates page on 2/8/2010, does not allow the use of the camera. With WPILib 4.2, whenever we use any AxisCamera methods in our C++ code, we get run-time errors about unresolved symbols on the cRIO (visible using NetConsole) and the camera doesn't work.

We are a rookie team and don't have enough experience yet with WindRiver C++ to put together our own custom linkages to work around this problem with the current WPILib release, as others on this thread are working to do. Heydowns generously posted a custom WPILib.a file to this thread on 2/10 that was created by their team to fix the problem with using AxisCamera, but Sunit pointed out that it brought back the unresolved _ZN16DriverStationLCD11kLineLengthE problem that was in the WPILib 4.1 release, which means we can't use both the AxisCamera and DriverStationLCD classes together in the same program (both of which we use heavily).

I'm getting nervous. Robot ship is in just 8 days, and we need to somehow get this resolved. I hope WPI posts an officially fixed WPILib for C++ in the next day or so. I also want to say, though, that we super appreciate all the volunteer work that Brad Miller and the rest of the WPI team do with creating and maintaining WPILib. I know it's a huge amount of work, and it lets us focus on the higher-level robot behavior programming with our team members.