OS X: Revert SIP fix for now

[mingwandroid]

@ilanschnell, @Msharan, @kalefranz, @pelson, @groutr, @jakirkham, @stuarteberg

It seems install_name_tool from OS X 10.7 is buggy regarding -delete_rpath. Another way forward will have to be found.

The proper fix (and even detection of the problem - I couldn't get a 10.7 VirtualBox image to work) is going to take a bit of time, I can't look at it for a while and there's no way I can leave things broken for that long. Unfortunately OS X 10.11 users of conda-build will face a minor regression, but that's less important.

I would appreciate it if everyone who's built binaries that have then failed to load could run:
strings $(install_name_tool 2>&1 | cut -d' ' -f2) | grep cctools
or:
strings $(which install_name_tool) | grep cctools
and also give me the md5sum of the real install_name_tool program (note that the first invocation above jumps through some hoops to get the right path since the install_name_tool in /usr/bin is just a stub - xcode-select probably? - to the real program).

Thanks all.

[mingwandroid]

Shall I go ahead and merge this? My access to computers is limited during GMT daytime at present, and I've not got OS X 10.7 with the broken install_name_tool with which to reproduce the problem, so I'd prefer if someone assisted with testing in that environment and then merging. My testing last night was 'ok', in that the 10.11 early conda-build failure of r-base due to SIP returned.

[msarahan]

IMHO, yes. I'm not sure if @ilanschnell or @kalefranz want to to do another conda-build release, but this does seem to be tripping up CI services in a few places, and would be a welcome fix.

[mingwandroid]

Thanks Mike.

It's tripping everyone up yeah. I think merging this is important.

Recompiling fixed binaries shouldn't be a problem if we must stick with old 10.7 tools. Getting Travis-ci to agree might be less easy but providing all the evidence should hopefully work to convince them.

I'll leave it with you guys then.

[jakirkham]

As mentioned back in the PR, I think we could consider switching 10.11 with XCode 7 and just set minimum supported Mac version to 10.7. This should generate binaries that remain compatible for the support Mac OS platforms (10.7 and above). This way we won't have the broken install_name_tool. There are already some other reasons to consider this.

[ilanschnell]

@jakirkham When you say "should", I take it that this hasn't been verified yet. In terms of building packages for the Anaconda distribution, I would feel much more comfortable staying on OSX 10.7. I do this now by simply using the conda-build 1.19.0 (which didn't have #808).

[stuarteberg]

As mentioned back in the PR, I think we could consider switching 10.11 with XCode 7 and just set minimum supported Mac version to 10.7.

In my experience, merely setting MACOSX_DEPLOYMENT_TARGET=10.7 isn't enough because recent versions of XCode no longer ship with the 10.7 SDK.

For example, I have Xcode 7.0, and here's what I see:

$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
MacOSX10.10.sdk/ MacOSX10.11.sdk/ MacOSX10.9.sdk/

You might be able to fish around on the Apple Developer website, download an old version of Xcode, extract the 10.7 SDK from it, and copy it into your own Xcode bundle. In theory, that ought to enable 10.7 deployment. But actually doing that -- and verifying that it works -- will be a real pain the butt. Any volunteers?

[stuarteberg]

BTW, does anaconda.org collect any usage statistics on people's OSX versions? That would be incredibly valuable.

Apple pushes OS upgrades pretty aggressively (and they tend to be free), so do we really think many people are still using really old versions? I really doubt that supporting 10.7 (which is 5 years old now) is a worthy goal. It's probably just a severe waste of everybody's time.

[mingwandroid]

I'll happily volunteer to look after building working historical versions of otools and getting them shipped by external projects, but can't for a few weeks.

[mingwandroid]

cctools rather!

[jakirkham]

That would be very awesome, @mingwandroid. Thank you. It would be really nice not to be building packages with broken dev tools.

[kalefranz]

Merged. Going to cut a release today or tomorrow.

[jakirkham]

Could please we get this as a bugfix release?

[jakirkham]

Maybe the frameworks approach isn't the right one, but I feel we should either use it or do something similar to what is proposed for Linux. Namely, building the newest version of the system compiler on the oldest supported system. The logic behind the Linux proposal seems very nice to me. As it would be possible to do so for Mac, it seems like another very logical way forward. As the Mac compiler takes a variety of non-standard arguments, this is the best way to ensure that builds expect to pass these can (e.g. Qt). Though I don't know what other tools might need to be built in this process.

[mingwandroid]

How Apple evolves their binary formats, Operating Systems and toolchains is quite vague to me.

As far as I know, they don't make the same promises that Windows (implicitly) and Linux (explicitly) make. Namely that you don't break user space or sometimes expressed as old executables must continue to work.

I'd love for someone to show me some documentation that proves me wrong and I'm aware of some nods towards backwards compatibility in their headers, environment variables and command line arguments but that's not really the same thing.

[jakirkham]

Just to clarify, this is in response to setting a minimum supported OS X version? Or is this in response to building a new system compiler on the old OS version with the old system compiler? Or both?