[ros-users] Request for Clue: OSX-specific linker flags, dependency resolution

[Jack O'Quin]

On Fri, Jan 14, 2011 at 10:41 AM, Nicholas Butko <nbutko at ucsd.edu> wrote:
> Jack, that patch looks exactly right. However, I am getting strange
> behavior.
> When I *haven't* applied the patch, this is my output:
> dyn137-110-111-179:camera1394 rubinet$ rosdep install camera1394
> Failed to find rosdep glut for package camera1394 on OS:macports
> version:macports
> Failed to find rosdep libdc1394-dev for package camera1394 on OS:macports
> version:macports
> ERROR: ABORTING: Rosdeps [u'glut', u'libdc1394-dev'] could not be resolved

> When I *have* applied the patch, this is my output:
> dyn137-110-111-179:camera1394 rubinet$ rosdep install camera1394
> Failed to find rosdep glut for package camera1394 on OS:macports
> version:macports
> ERROR: ABORTING: Rosdeps [u'glut'] could not be resolved
> I tried to fix this by adding an empty macports entry (macports: |) to
> everywhere that rosdep.yaml has "glut". From my investigation, this only
> seems to happen in the geometry package. Yet the problem persists.
> Another strange thing is that I get the same behavior *regardless of whether
> libdc1394 is installed* (It is easy to uninstall and reinstall).

Is this running cturtle or unstable? The camera_drivers stack does
depend on the geometry stack.

I just discovered that the vision_opencv stack also contains a
rosdep.yaml definition for libdc1394-dev, even less complete than the
one in camera_drivers. I don't know why openCV is built using
libdc1394, but if references from multiple stacks are needed, we
should probably combine them in some central place to avoid needing
multiple updates.

In an attempted fix for ticket #4659, I just committed two OSX changes
to camera_drivers trunk. Please test that on unstable and let me know
if it works for you.

I can easily make a similar fix for cturtle, assuming this one works
and there is interest in the OSX ROS community.
-- 
 joq