OSX: Building with xcode8 / 10.12 results in missing clock_gettime symbol

[springmeyer]

Using osx_image: xcode8 instead of osx_image: xcode7.3 on travis will trigger this error:

undef: _clock_gettime
Undefined symbols for architecture x86_64:
  "_clock_gettime", referenced from:
      boost::interprocess::spin_wait::yield() in lto.o
ld: symbol(s) not found for architecture x86_64
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)

[MoKob]

With #3284 merged, I guess this is solved? Closing under this assumption. Feel free to re-open otherwise.

[springmeyer]

#3284 worked around the issue by staying with osx_image: xcode7.3. This issue will re-appear when/if we move to osx_image: xcode8. Keeping closed since this is documented at

osrm-backend/.travis.yml

Line 56 in 538bbd4

# TODO: xcode8 triggers undefined symbol 'clock_gettime' in boost::interprocess

.

[daniel-j-h]

Could you follow up and check upstream with Boost if they're aware of the issue?
Otherwise this will hit us eventually.

[springmeyer]

Replicated this locally on OS X 10.11 with xcode8:

$ xcodebuild -version
Xcode 8.1
Build version 8B62

And this testcase:

#include <iostream>
#include <boost/interprocess/detail/os_thread_functions.hpp>

int main() {
    boost::interprocess::ipcdetail::get_current_system_highres_count();
    std::clog << "hello" << "\n";
    return 0;
}

Compiled liked:

$ clang++ -o t t.cpp -Imason_packages/headers/boost/1.61.0/include/ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -Wl,-bind_at_load

$ ./t
dyld: Symbol not found: _clock_gettime
  Referenced from: /Users/dane/projects/osrm-backend/./t (which was built for Mac OS X 10.12)
  Expected in: /usr/lib/libSystem.B.dylib
 in /Users/dane/projects/osrm-backend/./t
Trace/BPT trap: 5

There are a few workarounds I've found so far:

• Because setting xcode8.2 triggers using OS X 10.12 instead of 10.11 (https://docs.travis-ci.com/user/languages/objective-c/#Supported-Xcode-versions) then that also works around on travis.
• Locally on OS X 10.11 removing -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk from the compile flags avoids the problem. Therefore this also fixes osrm-backend build:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 4d3dc45..88342fd 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -296,8 +296,7 @@ endif()
 
 # Configuring other platform dependencies
 if(APPLE)
-  set(CMAKE_OSX_DEPLOYMENT_TARGET "10.10")
-  execute_process(COMMAND xcrun --sdk macosx --show-sdk-path OUTPUT_VARIABLE CMAKE_OSX_SYSROOT OUTPUT_STRIP_TRAILING_WHITESPACE)
+  unset(CMAKE_OSX_DEPLOYMENT_TARGET)
   set(CMAKE_OSX_ARCHITECTURES "x86_64")
   message(STATUS "Set Architecture to x64 on OS X")
   exec_program(uname ARGS -v  OUTPUT_VARIABLE DARWIN_VERSION)

[springmeyer]

Could you follow up and check upstream with Boost if they're aware of the issue?
Otherwise this will hit us eventually.

Because this problem goes away when upgrading to OS X 10.12 I think this is low priority. But if I have time I'll try to patch boost interprocess to see if that is another way to workaround.

[springmeyer]

#3347 solves this. Low priority to merge, but seems like a good idea to ensure we are working okay on 10.12 (as users start upgrading to it).

[daniel-j-h]

Tracked upstream: https://svn.boost.org/trac/boost/ticket/12617

[daniel-j-h]

Closing as not actionable on our side.

[springmeyer]

I'll also note: this only impacts the compile/link of example.cpp.

[springmeyer]

Back here to say:

I'll also note: this only impacts the compile/link of example.cpp.

Looks like this can also impact downstream deps like node-osrm per Project-OSRM/node-osrm#303

Tracked upstream: https://svn.boost.org/trac/boost/ticket/12617

This bug looks fixed 4 weeks ago, so perhaps when boost 1.64 comes out we'll have another workaround.

But overall I don't see this as critical to fix and okay to keep closed.
Project-OSRM/node-osrm#303