Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build issue on OS X #55

Open
mikepurvis opened this issue Aug 19, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@mikepurvis
Copy link

commented Aug 19, 2015

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.

@ghost

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2015

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 https://github.com/ros-controls/ros_controllers/pull/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

This comment has been minimized.

Copy link
Author

commented Aug 19, 2015

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.

@ghost

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2015

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

This comment has been minimized.

Copy link

commented Sep 22, 2016

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 added a commit to bhaskara/baxter_simulator that referenced this issue Sep 22, 2016

Fix ForwardCommandController linker error.
Provide an implementation of ForwardCommandController<T>::starting,
because it is not provided in the header.

Instead, it is in the source file joint_effort_controller.cpp.

Related: RethinkRobotics#55.
@bhaskara

This comment has been minimized.

Copy link

commented Sep 22, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.