crichardson332 / homebrew-crich_brews

Homebrew tap
0 stars 0 forks source link

Undefined symbols for architecture x86_64 #3

Closed jharrison closed 5 years ago

jharrison commented 5 years ago

Running make on our scrimmage project gives the following error (class name changed to MyAutonomyPlugin for privacy):

Scanning dependencies of target MyAutonomyPlugin_plugin
[ 25%] Building CXX object src/plugins/autonomy/MyAutonomyPlugin/CMakeFiles/MyAutonomyPlugin_plugin.dir/MyAutonomyPlugin.cpp.o
[ 28%] Building CXX object src/plugins/autonomy/MyAutonomyPlugin/CMakeFiles/MyAutonomyPlugin_plugin.dir/waypointgenerator.cpp.o
[ 31%] Linking CXX shared library ../../../../plugin_libs/libMyAutonomyPlugin_plugin.dylib
Undefined symbols for architecture x86_64:
  "scrimmage::autonomy::Waypoint::set_quat_tolerance(double)", referenced from:
      scrimmage::autonomy::MyAutonomyPlugin::init(std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >&) in MyAutonomyPlugin.cpp.o
  "scrimmage::autonomy::Waypoint::set_position_tolerance(double)", referenced from:
      scrimmage::autonomy::MyAutonomyPlugin::init(std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >&) in MyAutonomyPlugin.cpp.o
  "scrimmage::autonomy::Waypoint::Waypoint(double, double, double)", referenced from:
      scrimmage::autonomy::MyAutonomyPlugin::init(std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >&) in MyAutonomyPlugin.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]: *** [plugin_libs/libMyAutonomyPlugin_plugin.0.0.1.dylib] Error 1
make[1]: *** [src/plugins/autonomy/MyAutonomyPlugin/CMakeFiles/MyAutonomyPlugin_plugin.dir/all] Error 2
make: *** [all] Error 2
crichardson332 commented 5 years ago

This issue comes form the fact that the Waypoint class is currently located inside the WaypointGenerator plugin, and is built into a separate library than scrimmage-core. Since your plugins by default only link to scrimmage-core, they're not linking to this class. This can be fixed immediately by linking to the plugin in the cmake file, i.e. src/plugins/autonomy/MyAutonomyPlugin/CMakeLists.txt. Find where it says target_link_libraries( and it should currently only have one entry, scrimmage-core. Add WaypointGenerator_plugin right below scrimmage-core so it should look like:

target_link_libraries(${LIBRARY_NAME}
    scrimmage-core
    WaypointGenerator_plugin
  )

The Waypoint class is going to be moved to scrimmage-core since it's a general utility, but for now this should get you past the error.

jharrison commented 5 years ago

Okay, that worked. After fixing that I found two plugins that need to link MotorSchemas_plugin and two others that need Boundary_plugin. After adding those, it all compiles and links. Yay!

I'm puzzled that the linking works fine on our Ubuntu systems without this, but I'm glad it's building now. Several of our missions run, but it looks like there's a problem with the ones that use JSBSim. I'm make an issue for it.

crichardson332 commented 5 years ago

You shouldn't need to link MotorSchemas or Boundary - linking is not necessary to use a plugin. The only reason WaypointGenerator had to be linked is because it includes an extra utility class. If you look at scrimmage's source under src/plugins/autonomy, WaypointGenerator has two source files: WaypointGenerator.cpp, the plugin itself, and Waypoint.cpp, a utility class you're utilizing and need to link to. Most other plugins only have the one source file for the actual plugin, and don't need to be linked.

crichardson332 commented 5 years ago

Actually, I just noticed that MotorSchemas does have a utility class as well, so it does need to be linked if you're using BehaviorBase. The Boundary plugin however doesn't have a utility class, so it shouldn't need linking...

jharrison commented 5 years ago

Hmmm... judging from this, it looks like there are quite a few places where scrimmage plugins link Boundary_plugin, especially in the capture-the-flag mission stuff. Why would they need to link it if Boundary.cpp isn't a utility class?

crichardson332 commented 5 years ago

I'm not sure, that might be a mistake. scrimmage is an active research project that's had a ton of good development and changes over the last year, so there will definitely be some code throughout that is old/deprecated/unnecessary.

crichardson332 commented 5 years ago

User was instructed to link WaypointGenerator_plugin in the cmake list file for the plugin using the Waypoint class. This removed linker errors.

jharrison commented 5 years ago

I can confirm that scrimmage still builds after removing the link to Boundary_plugin from CMakeLists.txt for the following plugins: