crichardson332 / homebrew-crich_brews

Homebrew tap
0 stars 0 forks source link

Undefined symbols for architecture x86_64: boost::filesystem ... #7

Open jharrison opened 5 years ago

jharrison commented 5 years ago

I'm trying to use the boost::filesystem library in my autonomy plugin, following what I see in the scrimmage/missions/Straight.xml:

#define BOOST_NO_CXX11_SCOPED_ENUMS
#include <boost/filesystem.hpp>
#undef BOOST_NO_CXX11_SCOPED_ENUMS
namespace fs = boost::filesystem;

I also tried it without the define/undef but it makes no difference. If I call so much as fs::exists(filename) it generates the following error during make:

[ 76%] Building CXX object src/plugins/autonomy/TaskSpooler/CMakeFiles/TaskSpooler_plugin.dir/TaskSpooler.cpp.o
[ 78%] Linking CXX shared library ../../../../plugin_libs/libTaskSpooler_plugin.dylib
Undefined symbols for architecture x86_64:
  "boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)", referenced from:
      scrimmage::autonomy::TaskSpooler::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 TaskSpooler.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/libTaskSpooler_plugin.0.0.1.dylib] Error 1
make[1]: *** [src/plugins/autonomy/TaskSpooler/CMakeFiles/TaskSpooler_plugin.dir/all] Error 2
make: *** [all] Error 2
jharrison commented 5 years ago

Follow up: There are other boost libraries (e.g. boost/property_tree/ptree.hpp) that work fine in our plugin. It's only some of the boost libraries that have this problem. I noticed that scrimmage/src/CMakeLists.txt includes the following section:

target_link_libraries(${LIBRARY_NAME}
  PUBLIC
    scrimmage-protos
    scrimmage-msgs
    ${GeographicLib_LIBRARIES}
    ${CMAKE_DL_LIBS}
  PRIVATE
    Boost::boost
    Boost::filesystem
    Boost::program_options
    Boost::date_time
    Boost::graph
    Boost::thread
)

[Note: I confirmed that the same problem occurs when trying to boost::program_options.] So I tried modifying our TaskSpooler/CMakeFiles.txt to include the following:

target_link_libraries(${LIBRARY_NAME}
  PUBLIC
    scrimmage-core
    our-scrimmage-plugins-msgs
  PRIVATE
    Boost::filesystem
)

Running cmake .. produced the familiar error "readlink: illegal option -- f". I resolved this by changing readlink to greadlink in setup.bash, which got me as far as the following cmake error:

CMake Error at src/plugins/autonomy/TaskSpooler/CMakeLists.txt:11 (add_library):
  Target "TaskSpooler_plugin" links to target "Boost::filesystem" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
crichardson332 commented 5 years ago

If you link to Boost::filesystem in one of your plugins, you need to have a find_package(Boost REQUIRED COMPONENTS filesystem) in your project's top-level CMakeLists.txt file. Add any other components of Boost you need inside that find_package call next to filesystem.