Build issue on OS X

[mikepurvis]

Building on Indigo with clang:

[ 78%] Linking CXX shared library /Users/mikepurvis/ridgeback_ws/devel/lib/libbaxter_sim_controllers.dylib
cd /Users/mikepurvis/ridgeback_ws/build/baxter_simulator/baxter_sim_controllers && /usr/local/Cellar/cmake/3.3.1/bin/cmake -E cmake_link_script CMakeFiles/baxter_sim_controllers.dir/link.txt --verbose=1
/Library/Developer/CommandLineTools/usr/bin/c++   -dynamiclib -Wl,-headerpad_max_install_names  -o /Users/mikepurvis/ridgeback_ws/devel/lib/libbaxter_sim_controllers.dylib -install_name /Users/mikepurvis/ridgeback_ws/devel/lib/libbaxter_sim_controllers.dylib CMakeFiles/baxter_sim_controllers.dir/src/baxter_position_controller.cpp.o CMakeFiles/baxter_sim_controllers.dir/src/baxter_velocity_controller.cpp.o CMakeFiles/baxter_sim_controllers.dir/src/baxter_effort_controller.cpp.o CMakeFiles/baxter_sim_controllers.dir/src/baxter_head_controller.cpp.o /opt/ros/indigo/lib/libeffort_controllers.dylib /opt/ros/indigo/lib/libcontrol_toolbox.dylib /opt/ros/indigo/lib/libdynamic_reconfigure_config_init_mutex.dylib /opt/ros/indigo/lib/liburdf.dylib /usr/local/Cellar/urdfdom/0.2.10/lib/liburdfdom_sensor.dylib /usr/local/Cellar/urdfdom/0.2.10/lib/liburdfdom_model_state.dylib /usr/local/Cellar/urdfdom/0.2.10/lib/liburdfdom_model.dylib /usr/local/Cellar/urdfdom/0.2.10/lib/liburdfdom_world.dylib /opt/ros/indigo/lib/librosconsole_bridge.dylib /usr/local/lib/libtinyxml.dylib /opt/ros/indigo/lib/libclass_loader.dylib /usr/local/lib/libPocoFoundation.dylib /usr/lib/libdl.dylib /opt/ros/indigo/lib/libroslib.dylib /opt/ros/indigo/lib/librealtime_tools.dylib /opt/ros/indigo/lib/libroscpp.dylib /usr/local/lib/libboost_signals-mt.dylib /usr/local/lib/libboost_filesystem-mt.dylib /opt/ros/indigo/lib/librosconsole.dylib /opt/ros/indigo/lib/librosconsole_log4cxx.dylib /opt/ros/indigo/lib/librosconsole_backend_interface.dylib /usr/local/lib/liblog4cxx.dylib /usr/local/lib/libboost_regex-mt.dylib /opt/ros/indigo/lib/libxmlrpcpp.dylib /opt/ros/indigo/lib/libroscpp_serialization.dylib /opt/ros/indigo/lib/librostime.dylib /usr/local/lib/libboost_date_time-mt.dylib /opt/ros/indigo/lib/libcpp_common.dylib /usr/local/lib/libboost_system-mt.dylib /usr/local/lib/libboost_thread-mt.dylib /usr/local/lib/libconsole_bridge.dylib /usr/local/lib/libboost_system-mt.dylib /usr/local/lib/libboost_thread-mt.dylib /usr/local/lib/libconsole_bridge.dylib 
Undefined symbols for architecture x86_64:
  "forward_command_controller::ForwardCommandController<hardware_interface::EffortJointInterface>::starting(ros::Time const&)", referenced from:
      vtable for forward_command_controller::ForwardCommandController<hardware_interface::EffortJointInterface> in baxter_effort_controller.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [/Users/mikepurvis/ridgeback_ws/devel/lib/libbaxter_sim_controllers.dylib] Error 1
make[1]: *** [baxter_simulator/baxter_sim_controllers/CMakeFiles/baxter_sim_controllers.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Note that this was a Gazebo 5 setup, so it probably wouldn't have worked anyway (per #45), but this particular build issue appears to be on the ros_control side of things— generally clang is fussier about linker explicitness than gcc.

[rethink-imcmahon]

Oh, you're building my fancy forward_group_sim_controllers branch. Aside from being under heavy development (and under question as to whether or not to include this release), it requires ros-controls/ros_controllers#187 which is currently still an open PR.

If you experience any OSX build issues (Gazebo 2, 5, or 6) when building off of the development branch, please post them here and I'll add them to my stack. Thanks for reporting this.

[mikepurvis]

Hmm, I'm definitely on master for baxter_simulator and baxter_common, but I've tried development for baxter_simulator, and getting the same result.

Seems to build okay on Trusty/Indigo/Gazebo2/GCC, though.

[rethink-imcmahon]

That's super interesting, and possibly related to #45 as you say. I will have to figure out why the forward_command_controllers are being compiled into baxter_sim_controllers when they aren't being used...

[bhaskara]

Hi, is there any update on this? I'm trying to get baxter_simulator working on OS X and have run into this issue (also, if you know of any pointers on getting all of baxter_simulator running that would be much appreciated!)

[bhaskara]

Does the above make sense? There's just this screwy thing in ros_controllers where ForwardCommandController<T>::starting does not get implemented in forward_command_controller.h but in the source file joint_effort_controller.cpp, and so we run into the standard separate-compilation-doesn't-work-with-templates problem.