Bug #1570
0.7 version does not build on MacOS
| Status: | Resolved | Start date: | 07/22/2013 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | S. Wrede | % Done: | 100% | |
| Category: | cmake | |||
| Target version: | Robotics Service Bus - rsb-0.7 |
Related issues
History
#1 Updated by J. Moringen almost 11 years ago
- Description updated (diff)
#2 Updated by J. Moringen almost 11 years ago
- Assignee changed from J. Wienke to S. Wrede
#3 Updated by J. Wienke almost 11 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 almost 11 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 10 years ago
I didn't do anything special. Just the usual flags.
#6 Updated by S. Wrede over 10 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 10 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 10 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 over 10 years ago
- Status changed from Feedback to Resolved
Fixed (hypothesis: boost udpate on slave solved this).
#10 Updated by S. Wrede over 10 years ago
- % Done changed from 70 to 100