Bug #1570

0.7 version does not build on MacOS

Added by J. Moringen over 8 years ago. Updated about 8 years ago.

Status:ResolvedStart date:07/22/2013
Priority:NormalDue date:
Assignee:S. Wrede% Done:

100%

Category:cmake
Target version:Robotics Service Bus - rsb-0.7


Related issues

Related to Robotics Service Bus - Bug #1571: 0.7 version does not build on MacOS Resolved 07/22/2013

History

#1 Updated by J. Moringen over 8 years ago

  • Description updated (diff)

#2 Updated by J. Moringen over 8 years ago

  • Assignee changed from J. Wienke to S. Wrede

#3 Updated by J. Wienke over 8 years ago

H, looks like a make clean is missing. I think we updated the boost version with the homebrew update.

#4 Updated by S. Wrede over 8 years ago

Did you install boost with hombrew in the universal variant (32+64) bits?

From the log:

Linking CXX shared library ../build/librsc.dylib
Undefined symbols for architecture x86_64:
  "boost::filesystem::path::operator/=(boost::filesystem::path const&)", referenced from:
      boost::filesystem::operator/(boost::filesystem::path const&, boost::filesystem::path const&) in Environment.cpp.o
  "boost::this_thread::interruption_point()", referenced from:
      void boost::condition_variable_any::wait<boost::unique_lock<boost::recursive_mutex> >(boost::unique_lock<boost::recursive_mutex>&) in RepetitiveTask.cpp.o
      void boost::condition_variable_any::wait<boost::unique_lock<boost::recursive_mutex> >(boost::unique_lock<boost::recursive_mutex>&) in SimpleTask.cpp.o
  "boost::this_thread::hiden::sleep_until(timespec const&)", referenced from:
      boost::this_thread::sleep(boost::posix_time::ptime const&) in PeriodicTask.cpp.o
      boost::this_thread::sleep(boost::posix_time::ptime const&) in ThreadedTaskExecutor.cpp.o
  "boost::detail::once_epoch_cv", referenced from:

#5 Updated by J. Wienke over 8 years ago

I didn't do anything special. Just the usual flags.

#6 Updated by S. Wrede over 8 years ago

OK, I could reproduce the error on my machine with latest brew updates installed. It looks as if the linker command lacks the requiired boost dependencies but this needs further investigation.

#7 Updated by S. Wrede over 8 years ago

  • Category set to cmake
  • Status changed from New to Feedback
  • % Done changed from 0 to 70

The origin of this problem seems to be the call to FIND_PACKAGE(boost) in FindBoostUUID.cmake. For now, I reversed the order of boost and boost uuid checking in the rsc CMakeLists, which works on my machine and the Jenkins lion64 build slave.

Johannes: It would be great if FindBoostUUID.cmake can be implemented such that it does not expose this side effect.

#8 Updated by J. Wienke over 8 years ago

This was something introduced in more recent versions of cmake with an update in FindBoost. I already tried several things to get around this. In any case, we can start to drop FindBoostUUID completely now, since UUID is included in boost for some time now.

#9 Updated by S. Wrede about 8 years ago

  • Status changed from Feedback to Resolved

Fixed (hypothesis: boost udpate on slave solved this).

#10 Updated by S. Wrede about 8 years ago

  • % Done changed from 70 to 100

Also available in: Atom PDF