Compilation failure with macOS 10.12 SDK

[scpeters]

A build failure of simbody 3.5.3 was reported in osrf/homebrew-simulation#135 (full details here) that can be summarized with the following error message:

In file included from /tmp/simbody-20160920-28673-1o5ma3f/simbody-Simbody-3.5.3/SimTKcommon/src/Timing.cpp:33:
/tmp/simbody-20160920-28673-1o5ma3f/simbody-Simbody-3.5.3/
SimTKcommon/./include/SimTKcommon/internal/Timing.h:88:18:
error: typedef redefinition with different types ('long' vs 'enum clockid_t')
    typedef long clockid_t;
                 ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/
Developer/SDKs/MacOSX10.12.sdk/usr/include/time.h:171:3: 
note: previous definition is here
} clockid_t;
^

They were using macOS 10.11 but with the macOS 10.12 SDK, which appears to define the clockid_t type. This will probably cause the same build failures on macOS 10.12 when it is released. Thanks to @bwithbroe and @uframer for reporting this issue.

[chrisdembia]

Thank you for reporting this.

This will probably cause the same build failures on macOS 10.12 when it is released.

10.12 was released today!

@sherm1 I can try to fix this. Let me know if you have any suggestions on the fix.

[chrisdembia]

Related:

• xz broken on OSX 10.11.6 Beta (15G24b) with XCode 8 Beta Homebrew/homebrew-core#2674
• macOS 10.12 and Xcode 8.0 broken formulae Homebrew/homebrew-core#1957
• https://github.com/civetweb/civetweb/pull/356/files
• https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html#//apple_ref/doc/uid/10000163i-CH1-107837
• https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW6

[sherm1]

Hi, @chrisdembia. Thanks for volunteering to fix this! Looks like I had to fake clockid_t and clock_gettime() for earlier OSX versions (in Timing.h). If you can figure out what magic #ifdef determines whether OS 10.12's SDK is in use, those definitions could be skipped.

[chrisdembia]

Thank you for merging #524. Do you think we should make a new release (3.5.4), so that a released version of Simbody supports macOS 10.12?

[sherm1]

Do you think we should make a new release (3.5.4)

To do that would require a backport to the simbody-3.5 branch since #524 went into the master (3.6) version. That would allow C++03 compilations on 10.12 -- is that still useful? Otherwise we could consider just including that in a 3.6 release with the other new goodies there. (With C++11 required.)

[chrisdembia]

I am fine with having this bug fix in a 3.6 release. My reason for suggesting 3.5.4 instead was that I thought a 3.6 release was not ready yet, and it would be nice to have the bug fix release somewhat soon. But if you think the 3.6 release could be soon, then we do not need to backport.

[bwithbroe]

Do you have a rough release schedule for 3.6?

[sherm1]

Do you have a rough release schedule for 3.6?

Not yet. @chrisdembia and I need to discuss to decide whether 3.6 is really ready to go now. Otherwise the 3.5.4 options sounds good - how fast do you need it?

[scpeters]

Also related: Homebrew/brew#1078

[chrisdembia]

Thank you for sharing, @scpeters. Is the idea that Simbody could use a CMake variable HAVE_CLOCK_GETTIME to decide if we should define clock_gettime()? To make good use of this variable, wouldn't Simbody's CMake scripts have to detect if they were being run as part of Homebrew?

[scpeters]

I was just posting that for reference; I think it won't solve the issue for people building simbody from source without homebrew, but it may resolve the issue of people building simbody 3.5.3 with homebrew with xcode 8 on macOS 10.11. Maybe not actually, since it says it addresses lazy linking but it probably won't fix the compilation errors?

[chrisdembia]

Ah good point...

[bwithbroe]

@sherm1 - I'm working on a project that requires simbody as a dependency for something else. For now I can use a lab machine (and the other members of the team can run it fine, since they already compiled simbody). Sooner rather than later would be nice but I don't have any hard deadlines.

[chrisdembia]

@scpeters and @bwithbroe: Simbody 3.5.4 has been released. This version of Simbody incorporates the fix for Xcode 8 and MacOSX10.12.sdk.

[daveminh]

I just compiled SimBody using cmake for the first time.

I downloaded SimBody 3.5.4. I compiled it on Mac OS X 10.11.6 with Xcode Version 8.0 (8A218a) and CMAKE_OSX_SYSROOT set as /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk.

I got this issue:

Minh-IIT-MBP:simbody-build dminh$ ./ExamplePendulum
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
Referenced from: /Users/dminh/Applications/simbody-build/libSimTKsimbody.3.5.dylib (which was built for Mac OS X 10.12)
Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _clock_gettime
Referenced from: /Users/dminh/Applications/simbody-build/libSimTKsimbody.3.5.dylib (which was built for Mac OS X 10.12)
Expected in: /usr/lib/libSystem.B.dylib

dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
Referenced from: /Users/dminh/Applications/simbody-build/./simbody-visualizer (which was built for Mac OS X 10.12)
Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _clock_gettime
Referenced from: /Users/dminh/Applications/simbody-build/./simbody-visualizer (which was built for Mac OS X 10.12)
Expected in: /usr/lib/libSystem.B.dylib

Trace/BPT trap: 5

[chrisdembia]

Thanks for trying this out @daveminh.

What was your CMAKE_OSX_DEPLOYMENT_TARGET? Make sure it was 10.11. Since the error message says ...built for Mac OS X 10.12, it seems like your CMAKE_OSX_DEPLOYMENT_TARGET was 10.12.

[daveminh]

Okay thanks. I just updated to Mac OS X 10.12 and it worked. I didn't set CMAKE_OSX_DEPLOYMENT_TARGET to any value. so I guess it was 10.12.