OSX_DEPLOYMENT_TARGET 10.9 or later required with ITKv5

Engineering
, ,
1

Hi folks,

If you do not build macOS binaries for distribution that target compatibility with older OS versions, you can ignore this thread.

As a consequence of the C++11 requirement of ITKv5, macOS builds that specify OSX_DEPLOYMENT_TARGET, e.g. through the CMAKE_OSX_DEPLOYMENT_TARGET variable, will require a version of 10.9 or later. Since 10.9 builds use libc++, which has sufficient C++11 support, they will build, unlike earlier versions, which use an old libstdc++.

M

CC: @blowekamp @hjmjohnson

2

Matt,

Thanks for moving this discussion here! And for submitting those builds to the dashboard.

Yes, it appears that the Apple’s GNU libstdc++ is old and does not properly support C++11, even with the -std=c++11. Compiling the current ITK, results in compilation errors in the VNL related to std::shared_ptr not being available as your builds show.

By default, when OSX_DEPLOYMENT_TARGET=10.9 libc++ is used, which is required for using c+11. However, libc++ is available with OSX_DEPLOYMENT_TARGET=10.7. So configuring the current ITKv5 development with the following works:

 cmake  -DCMAKE_CXX_FLAGS=-stdlib=libc++ -DCMAKE_OSX_DEPLOYMENT_TARGET=10.7  ~/src/ITK

Resulting in the following executables:

$ otool -L bin/itkTestDriver 
bin/itkTestDriver:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)

While the Apple system python (2.6,2.7) uses it’s own os version for the min OS X:

lhcp-vm-osx11-1$ /usr/bin/python  -c "import distutils.util; print(distutils.util.get_platform())"
macosx-10.11-intel
lhcp-vm-osx11-1$ /usr/bin/python2.6  -c "import distutils.util; print(distutils.util.get_platform())"
macosx-10.11-intel

the python.org distribution is still stuck at 10.6:

lhcp-vm-osx11-1$ /usr/local/bin/python3.5 -c "import distutils.util; print(distutils.util.get_platform())"
macosx-10.6-intel
lhcp-vm-osx11-1$ /usr/local/bin/python3.4 -c "import distutils.util; print(distutils.util.get_platform())"
macosx-10.6-intel
lhcp-vm-osx11-1$ /usr/local/bin/python2.7 -c "import distutils.util; print(distutils.util.get_platform())"
macosx-10.6-intel

I am unaware of a Python PEP for a recommendation on OS X binaries nor what c++ library to use.

The Spinning Wheels Mac Python is old and does not address libc++ issues.

3

Yes, CMAKE_CXX_FLAGS can be used to augment CMAKE_OSX_DEPLOYMENT_TARGET. That is another option, though it is more difficult to apply.

This page shows that other binary Python distributions are using OSX_DEPLOYMENT_TARGET 10.9.

4

It is unclear when that table was updated. I just showed the current Python.org distributions are stuck at 10.6. I’m not sure where home-brew/Mac ports are, but I’d guess they are on a very recent version.

There is also Anaconda, which appears to be developing their own toolchain which uses the 10.9 framework, but I don’t see and indication of neither what C++ library they are using nor what min OS X deployment target. From my recent miniconda installations I am getting the following report:

$ ~/miniconda2/bin/python2.7 -c "import distutils.util; print(distutils.util.get_platform())"
macosx-10.7-x86_64
$ ~/miniconda3/bin/python3.6 -c "import distutils.util; print(distutils.util.get_platform())"
macosx-10.7-x86_64

Additionally they seem to be using libc++

$ otool -L ~/miniconda3/lib/*.dylib |grep c++
/Users/blowekamp/miniconda3/lib/libc++.1.0.dylib:
	@rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 48.0.0)
	@rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/blowekamp/miniconda3/lib/libc++.1.dylib:
	@rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 48.0.0)
	@rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/blowekamp/miniconda3/lib/libc++.dylib:
	@rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 48.0.0)
	@rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/blowekamp/miniconda3/lib/libc++abi.1.0.dylib:
	@rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/blowekamp/miniconda3/lib/libc++abi.1.dylib:
	@rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/blowekamp/miniconda3/lib/libc++abi.dylib:
	@rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)

IMHO, I think we can keep the check for requiring 10.7, but that is not sufficient to determine that compiler configuration will work. I’d expect that the CMake WriteCompilerDetectionHeader would be more aware of these compiler options to generate compliant results. As these extra configuration flags ( specifying OSX_DEPLOYMENT_TARGET) are not commonly used by default and geared towards packaging, it may be ok not to have a complete check and leave the code as it is.

5

Typo? That shows it uses libc++ (from llvm), not libstdc++ (from GNU).

6

Corrected

7

This is reasonable.