Removal of libstdc++ reminants from the stack on Mac

[jakirkham]

So, there has been a lot of discussion and in some case frustration with segmentation faults caused by a mixture libstdc++ and libc++ being used. Basically, these libraries cannot pass C++ objects between each other. However, passing C objects is totally fine. Over the past few weeks @gillins and myself have been addressing this in the stack. Though it seems there is lots of confusion or simply lack of knowledge about this problem in general. As a result, I'm writing this up to discuss what is happening, why it is happening, what we are doing to fix, and how people can help. To start, let's get some history about the choices we have made.

Why clang/clang++/libc++? First, on Mac the gcc/g++/libstdc++ went unmaintained some time ago and got converted to a frontend to clang/clang++. Second, the libstdc++ library seems to be missing on newer OS X's (e.g. 10.11) from my experience, which causes issues using gcc/g++. Third, users often want to use new C++ features like C++11, which is only possible with clang++ and libc++. As a result, we accepted the use of clang/clang++/libc++ as our de facto toolchain.

However, it is hard to get software to pickup clang/clang++ and use libc++ for some reason. Instead things like to pick up the dated gcc and g++. So, we figured out some environment variables that mostly worked and copied them around. The suggestion at that time by @wesm and others was we should package this up. Personally I was feeling overwhelmed just staying on top of notifications related to building on Mac and this sounded like a good way to address that. So, we wrote the toolchain to try to set those automatically. The hope was this should make it easy for people to use and recommend, and it let me return to a lower volume of pings (but still remained quite busy).

Still there were many pieces of code that already entered the ecosystem that were built before we made the decision to use clang/clang++/libc++ and before the creation of the toolchain. Now this is a very serious problem as these pieces of software are using libstdc++. Why is this a problem? Because if C++ objects pass from a library using libc++ to libstdc++ or vice versa one will get segmentation faults. The only exception is exception objects, which can be thrown across the boundary. This causes people all sorts of issues see this thread, these recommendations, and this detail explanation of where this does or doesn't cause problems. However, we really can't be digging into code to see if might be ok (unless we know that code well) so we should be switching everything else to clang/clang++/libc++. This is what @gillins and I set out to do with the toolchain in hand.

While the toolchain does work ok in many cases, there is no guarantee that there won't occasionally be software that needs special hand holding. @gillins and myself have already watched libtool gobble up some flags that we are passing around. We still don't know why that is the case, but there are plenty of reports of this behavior like this SO question, this upstream patch (note the silence that follows), this Macports issue, this FreeBSD thread, etc. (really this list goes on and on). This problem is not exclusive to our libtool, but affects the system libtool. The workaround we have used is forcing -stdlib=libc++ in CC and CXX. It is not pretty, but it works with libtool. However, the workaround does not work (nor is it needed) with cmake. We could look at patching our libtool. Though it doesn't seem the patch has been accepted upstream or whether it ever will. That being said, maybe it saves some pain. There may be other special cases I don't yet know of please feel free to share them here.

cc @gillins @pelson @ocefpaf @msarahan @kmuehlbauer

[mwiebe]

This sounds roughly the same as targeting different MSVC versions on Windows, is there a possibility to introduce a metapackage/feature selection here just as is being discussed for that?

[pelson]

Thanks @jakirkham. Really useful information! How does this compare with the libraries available on defaults - are they compiled with the clang which is a frontend on gcc, and if so, are we likely to see problems if we mix conda-forge and defaults distributions?

[jakirkham]

FYI this is the other issue that I mentioned that came up in issue ( conda-forge/numpy-feedstock#15 ).

[jakirkham]

This sounds roughly the same as targeting different MSVC versions on Windows...

However, the situation is not so bad as the C APIs between clang built stuff and gcc built stuff are 100% compatible. So, Python bound libraries that use libstdc++ can be totally fine as they use Python's C API.

[jakirkham]

is there a possibility to introduce a metapackage/feature selection here just as is being discussed for that?

The point is we shouldn't be using libstdc++ at all at present. So I think coming up with this sends the wrong message.

[ChrisBarker-NOAA]

On Fri, Jul 1, 2016 at 9:15 AM, jakirkham [email protected] wrote:

This sounds roughly the same as targeting different MSVC versions on
Windows...

However, the situation is not so bad as the C APIs between clang built
stuff and gcc built stuff are 100% compatible. So, Python bound libraries
that use libstdc++ can be totally fine as they use Python's C API.

If you are using only C, are you using libstdc++ or libc++ at all? is the
libc part of those, or are the separate anyway?

In any case, IIUC, libc++ (and clang) have been around for a long enough
time that we can standardize on it for ALL C++ on OS-X for the Anaconda /
conda-forge environment -- is that right? So the "only" trick is to get
all the build tools to use it, yes?

BTW, python3.6 isn't out yet, so there is room to update the compiler used
there. Personally, I think 3.6 should dump 32 bit, and go to a more modern
base OS-X version, which I think would allow going to clang, and libc++ by
default as well, yes?

If there is input from the computation computing community to python-dev,
we may be able to make that happen.

-CHB

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

[email protected]

[kmuehlbauer]

@jakirkham Thanks for writing this paper 👍

I do not question a toolchain in general. At the moment it brings (besides doing good at trying to solve the libc++ riddle) many problems with it.

As seen in conda-forge/gdal-feedstock#85 there are packages where configure in combination with libtool broke by using the toolchain on osx as well as linux. Where should this be fixed?

As this is mainly to target osx libc++ issues I personally would split this into parts (osx-toolchain, linux-toolchain) or drop it completely on linux.

[jakirkham]

... clang which is a frontend on gcc...

Minor clarification. On Mac gcc is a frontend to clang. Depending on what Mac OS version you have, you may be in a different point on this transition. Suffice it to say that the last time gcc was a standalone compile was 10.6. On 10.7 it became a frontend to clang. On 10.9 clang is basically the default compiler. So, changes like the recently accepted PR ( conda-forge/toolchain-feedstock#9 ) will make our lives significantly easier.

How does this compare with the libraries available on defaults - ...if so, are we likely to see problems if we mix conda-forge and defaults distributions?

I'm not really sure about all the things. Though there are many offerings in defaults that are C-based. So, those don't factor into this discussion.

There are some libraries that use C++ internally, but only expose a C API. Those don't cause issues in terms of C++ object passing as they don't do it. Examples include SciPy as confirmed by @rgommers. Though I have had some installation issues on some customer machines that use 10.11. So, it might be best to avoid it in those case too. See PR ( conda-forge/scipy-feedstock#2 ) for the SciPy change to libc++.

The few big ones that come to mind that could be issues are Boost. Though we have packaged this and ours uses libc++. Just about everything that here that uses Boost also requires C++11 support so is also on libc++ for this reason. So, it doesn't cause problems, but if their version trumps ours we are going to have issues in many places in our stack. Something to be mindful of.

Also, I am pretty sure Qt4 uses libstdc++. That being said, most people are interfacing with it from Python via PyQt4 or PySide. In that case, the C++ objects are all contained within those libraries as the C API is used with Python. So, that shouldn't cause issues. People directly linking to Qt4 should be mindful of this issue though. Particularly if they are using Boost too. Qt5 won't have this issue as it requires C++11 and so is being built with libc++ at present.

HDF5 was recently switched to libc++ here to fix some issues as it was using libstdc++ and preceded these decisions. I believe defaults uses libstdc++ in that case.

I don't really know the extent and manner C++ is used in libraries like gdal and related application libraries in defaults. There is a transition undergoing in that area, but it seems that people are running into some issues ( conda-forge/gdal-feedstock#85 ) getting the configuration to work. Unfortunately I don't have much time to invest in sorting this out at present and will be out until Wednesday. Though I would encourage them not to lose hope that these issues while annoying are solvable. I do really want to help as soon as I have more time. It might be worth patching our libtool even if that patch doesn't appear to be going anywhere upstream and has some conflicts.

If things get too hairy, I'd be ok blasting gcc, g++, and libstdc++ off Travis CI completely. We just have to be careful as discussions of offline builds are coming into the mix. So we will still need to consider how to get that configuration working correctly.

[ocefpaf]

If things get too hairy, I'd be ok blasting gcc, g++, and libstdc++ off Travis CI completely.

IMO that is the way to proceed for now until we have a better solution.

@gillins, @msarahan, @kmuehlbauer, @pelson and all of @conda-forge/core maybe we could take a vote on this? (It can be 👍 or 👎 here to reduce the noise.)

[jakirkham]

I do not question a toolchain in general. At the moment it brings (besides doing good at trying to solve the libc++ riddle) many problems with it.

No worries. It's an imperfect solution for an OS (OS X) that is in transition. Sadly they have not put gcc out of it's misery on that platform like they probably should.

As seen in conda-forge/gdal-feedstock#85 there are packages where configure in combination with libtool broke by using the toolchain on osx as well as linux. Where should this be fixed?

I have not followed that as closely as I probably need too. Was a bit worried that we were headed towards breakage in there. So I wanted to try and communicate everything I could to make sure we all understand the issues.

I need to get my bearings with that PR. Maybe a short explanation of what is going at the bottom of that PR will help.

libtool is a mess. MacPorts decided to patch libtool. Even after upstream did nothing and said nothing about the provided patch. Maybe we should try the same. Our libtool is newer though. So we may need to fix some conflicts (IIRC there were some) with the patch.

As this is mainly to target osx libc++ issues I personally would split this into parts (osx-toolchain, linux-toolchain) or drop it completely on linux.

Feel free to apply the toolchain just to OS X in that PR if it helps. I'm far more concerned about libc++ and libstdc++ breakage than I am about applying the toolchain selectively at this point. Some of the comments suggested this strategy was tried and didn't work. Though I really haven't read the whole thing in detail. So I may be badly misinformed.

[jakirkham]

Sorry if this feels noisy, @ocefpaf. I'm a bit worried that only @gillins and I have had all the facts on this issue up to now, but decisions were being pushed without them. So I wanted to try to provide the info to people and answer questions as they came up.

[jakirkham]

Sorry, this got lost in the mix @ChrisBarker-NOAA.

If you are using only C, are you using libstdc++ or libc++ at all?

No.

If you are all C, this doesn't matter basically.

is the libc part of those, or are the separate anyway?

Not really. This ends up getting baked into the OS. That being said, there is no problem passing back and forth C objects. So, C libraries can be built with either system compiler without issue. On Mac, this means that one is linked to libSystem and whatever else one intentionally links to.

In any case, IIUC, libc++ (and clang) have been around for a long enough
time that we can standardize on it for ALL C++ on OS-X for the Anaconda /
conda-forge environment -- is that right?

We should totally be able to standardize on libc++. Continuum can even use it with their 10.7 constraint no problem.

However, the question came up a few weeks back about rebuilding and using the Continuum gcc package (probably as some 5.x). Given this, we have to figure out the right amount of effort we want to spend here. My interest is eliminating the currently broken user experience. I'm not sure it is worth the effort to go much beyond that if we change to gcc soon.

The question is what is soon for that switch. @msarahan estimated a week or two to build it. Though I think that is assuming that he gets a whole week or two to do so. In reality his time seems to be under high demand. So, I'm unclear whether it will happen in the next month or next few months. Also, this assumes we don't hit a big snag building gcc or have issue trying to use it.

So the "only" trick is to get all the build tools to use it, yes?

Haha. Yeah. We can see this is a bit tricky from experience. Though it is doable and I think @gillins and I have made progress at simplifying the situation.

We might have to accept some less desirable things like patching libtool even if upstream seems unresponsive to the patch. That strategy worked wonders for MacPorts, which only uses their libtool (not the system libtool) to build everything.

BTW, python3.6 isn't out yet, so there is room to update the compiler used
there.

So, Python is all C. As stated before, this doesn't factor into the discussion. In fact, I think by having it only be C this problem is way simpler than it would be if it were C++.

Personally, I think 3.6 should dump 32 bit, and go to a more modern
base OS-X version, which I think would allow going to clang, and libc++ by
default as well, yes?

Yeah, I have one computer that is a 6 year old MacBook Pro on 10.6 that is on its dying bed and it still has 64-bit. 10.7 had 64-bit only. Definitely time to cut the cord with 32-bit on Mac.

So, dropping 32-bit means dropping 10.6. AFAICT Continuum only supports 10.7 and up. Also 10.7 includes the introduction of clang++ and libc++ that support C++11. That really just solves lots of problems.

If there is input from the computation computing community to python-dev, we may be able to make that happen.

A few weeks back we decided that we only care about 10.9 at conda-forge. It is probably the only issue I know of that had zero controversy and overwhelming support all the way up to demand.

I'm all in favor of having us write a letter to get Python using clang and setting 10.7 as the lower end at least. I think they try to build for 10.5 now, which is silly. That OS is so different from the modern OS X that we might as well be on 11.0.

[ChrisBarker-NOAA]

On Fri, Jul 1, 2016 at 11:21 AM, jakirkham [email protected] wrote:

BTW, python3.6 isn't out yet, so there is room to update the compiler used
there.

So, Python is all C. As stated before, this doesn't factor into the
discussion. In fact, I think by having it only be C this problem is way
simpler than it would be if it were C++.

yes, but it bakes the compiler version, etc into distutils. so IIUC, if you
do a siple distutils build with the pyton.org Python, you still get the
old gcc, and the old C++ lib. which hoses you if you are using an extension
to call a C++ lib built with the newer one.

Personally, I think 3.6 should dump 32 bit, and go to a more modern

base OS-X version, which I think would allow going to clang, and libc++ by
default as well, yes?

Yeah, I have one computer that is a 6 year old MacBook Pro on 10.6 that is
on its dying bed and it still has 64-bit. 10.7 had 64-bit only. Definitely
time to cut the cord with 32-bit on Mac.

So, dropping 32-bit means dropping 10.6. AFAICT Continuum only supports
10.7 and up. Also 10.7 includes the introduction of clang++ and libc++
that support C++11. That really just solves lots of problems.

yeah. Though last I talked to Ned Deily about this, he was still leaning
toward keeping 10.6 support, as you could still go newer with extensions
and it should all still work. but I think that just complicates the mess
for everyone -- better to be clear.

And though we are trying to keep a consistent conda environment where we
can set our own standards, it would be nice to keep stuff in line with
folks building wheels for PyPi , etc.

A few weeks back we decided that we only care about 10.9 at conda-forge.
It is probably the only issue I know of that had zero controversy and
overwhelming support all the way up to demand.

Good data point. Though the computational community is a bit less likely to
be running old stuff than some others.

I'm all in favor of having us write a letter for get Python using clang
and setting 10.7 as the lower end at least. I think they try to build for
10.5 now, which is silly. That OS is so different from the modern OS X that
we might as well be on 11.0.

not quite -- it's 10.6. There was 10.5 support for 32bit-Intel+PPC, but
they've given up on that for 3.5, anyway.

I think 3.6 should support only the oldest version that Apple still
supports -- not sure what that is. And some semi-deep googling is not
helping :-(

-CHB

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

[email protected]

[rgommers]

I think 3.6 should support only the oldest version that Apple still supports -- not sure what that is. And some semi-deep googling is not helping :-(

Apple doesn't publish end of support dates, but the last security update for 10.6 was back in 2013. See http://www.computerworld.com/article/2487996/malware-vulnerabilities/apple-retires-snow-leopard-from-support--leaves-1-in-5-macs-vulnerable-to-at.html

python.org builds should definitely drop 32-bit for Python 3.6, but I wouldn't be surprised if it doesn't happen due to inertia. A letter sounds like a great idea.

[ChrisBarker-NOAA]

On Fri, Jul 1, 2016 at 12:59 PM, Ralf Gommers [email protected]
wrote:

I think 3.6 should support only the oldest version that Apple still
supports -- not sure what that is. And some semi-deep googling is not
helping :-(

Apple doesn't publish end of support dates, but the last security update
for 10.6 was back in 2013. See
http://www.computerworld.com/article/2487996/malware-vulnerabilities/apple-retires-snow-leopard-from-support--leaves-1-in-5-macs-vulnerable-to-at.html

yeah, that's long gone -- and I'm pretty sure 10.8 is no longer supported
-- don't know about 10.9

I just asked my IT folks, they apparently get work from their security scan
vendor that "you're runnign a version that is no longer supported" -- but
no one seems to know how they find out...

python.org builds should definitely drop 32-bit for Python 3.6, but I

wouldn't be surprised if it doesn't happen due to inertia. A letter sounds
like a great idea.

I'm not sure where a letter would be sent, but discussion on python-dev
would be a good start.

-CHB

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

[email protected]

[rgommers]

(digital letter). python-dev is indeed the appropriate place I think. What I understood @jakirkham meant by "letter" is a clear story in support of dropping 10.6 and 32-bit support, sent by someone to for example python-dev in the name of a larger group of people.

[ChrisBarker-NOAA]

On Fri, Jul 1, 2016 at 2:25 PM, Ralf Gommers [email protected]
wrote:

(digital letter). python-dev is indeed the appropriate place I think. What
I understood @jakirkham https://github.com/jakirkham meant by "letter"
is a clear story in support of dropping 10.6 and 32-bit support, sent by
someone to for example python-dev in the name of a larger group of people.

sure -- any idea where we can coordinate this group? the numpy or scipy
lists, maybe?

-CHB

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#183 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AA38YIJZfsM9hNs4eCuGMWHXy_jIcDfvks5qRYXegaJpZM4JDNsF
.

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

[email protected]

[rgommers]

composing it here plus a ping to @matthewbrett (who just suffered through the pain of building dual-arch wheels) would be a good start.

[jakirkham]

Yep, this is a serious and related issue. I'm more than happy to have the letter written here. Don't know if you have a medium of preference. We have done Google Docs in the past and allowed anyone with a link to edit. Here's a link for this one ( https://docs.google.com/document/d/1AQNGU726hLfvDPQCe7SJjclxQ4fgL4V1ryLh2xUuNIM/edit?usp=sharing ).

[jakirkham]

If you would prefer something different, we also have Hackpad as an option. Though other suggestions are welcome.

[rgommers]

Thanks, GDocs works fine I'd say.

[rgommers]

not quite -- it's 10.6. There was 10.5 support for 32bit-Intel+PPC, but they've given up on that for 3.5, anyway.

Looks to me like they haven't - there's a separate i386/PPC installer for OS X 10.5 at https://www.python.org/downloads/release/python-352/.

[mwcraig]

Coming back around to this:

If things get too hairy, I'd be ok blasting gcc, g++, and libstdc++ off Travis CI completely.

IMO that is the way to proceed for now until we have a better solution.

Do we, yea or nay, (with 👍 or 👎 ) need to remove gcc, etc as a temporary fix?

(I'm reposing @ocefpaf's question, which neatly avoids the need for me to vote on it, since there isn't a reaction emoji for :mostly ignorant of the details:)

[gillins]

Thanks for writing this up @jakirkham .

One other thing to consider before we start patching libtool is to use the config.site mechanism (see https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Site-Defaults.html). I've used this on Linux and Solaris with quite a bit of success before. Is this something you have used?

If I have a chance I'll see if building gdal on OSX works in this way without breaking anything else.

[jakirkham]

A few weeks back we decided that we only care about 10.9 at conda-forge.
It is probably the only issue I know of that had zero controversy and
overwhelming support all the way up to demand.

Good data point. Though the computational community is a bit less likely to
be running old stuff than some others.

Honestly, I don't if I would normally agree with that, @ChrisBarker-NOAA. I remember getting stuff built on my ancient 10.6 Mac and once it was working I was extremely reluctant to update as I would have to go back through that process with a new OS. With the impact of conda and conda-forge, I think this is changing for the positive though.

[jakirkham]

One other thing to consider before we start patching libtool is to use the config.site mechanism (see https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Site-Defaults.html). I've used this on Linux and Solaris with quite a bit of success before. Is this something you have used?

I have not, @gillins. Though I'm willing to learn about it and give it a try if it could help. As mentioned elsewhere, this would be a great thing to add to the toolchain to make people's lives easier.

[ChrisBarker-NOAA]

On Fri, Jul 1, 2016 at 3:24 PM, Ralf Gommers [email protected]
wrote:

not quite -- it's 10.6. There was 10.5 support for 32bit-Intel+PPC, but
they've given up on that for 3.5, anyway.

Looks to me like they haven't - there's a separate i386/PPC installer for
OS X 10.5 at https://www.python.org/downloads/release/python-352/.

my mistake -- I guess the build scripts are there, so why not?

I'm pretty sure no one's going to do that for 3.6 though.

-CHB

[ChrisBarker-NOAA]

On Sat, Jul 2, 2016 at 12:47 PM, jakirkham [email protected] wrote:

A few weeks back we decided that we only care about 10.9 at conda-forge.I
remember getting stuff built on my ancient 10.6 Mac and once it was working
I was extremely reluctant to update as I would have to go back through that
process with a new OS. With the impact of conda and conda-forge, I think
this is changing for the positive though.

Good point -- though what that means is that the conda community is less
likely to be concerned with backward compatibility -- so maybe a bit harder
to do for the python.org installers...

-CHB

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

[email protected]

[ChrisBarker-NOAA]

On Fri, Jul 1, 2016 at 2:49 PM, jakirkham [email protected] wrote:

Here's a link for this one (
https://docs.google.com/document/d/1AQNGU726hLfvDPQCe7SJjclxQ4fgL4V1ryLh2xUuNIM/edit?usp=sharing
).

I added some more test -- someone please go in and make sure I didn't add
anything incorrect. It could use some more fleshing out, too.

And add your name to the bottom, as well...

@matthewbrett https://github.com/matthewbrett: I hope you can take a
moment to add your $0.02 -- both because of your expertise and experience,
and because it would be nice for this to no look like a "conda only"
concern.

-Chris

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

[email protected]

[rgommers]

I'm all in favor of having us write a letter to get Python using clang and setting 10.7 as the lower end at least. I think they try to build for 10.5 now, which is silly. That OS is so different from the modern OS X that we might as well be on 11.0.

The default stdlib changed to libc++ only on 10.9, so I changed the proposal to that.

[ChrisBarker-NOAA]

Thanks Ralf -- I just fixed a couple typos -- now I think we need more
review and certainly more names at the bottom :-)

-CHB

On Mon, Jul 4, 2016 at 3:11 PM, Ralf Gommers [email protected]
wrote:

I'm all in favor of having us write a letter to get Python using clang and
setting 10.7 as the lower end at least. I think they try to build for 10.5
now, which is silly. That OS is so different from the modern OS X that we
might as well be on 11.0.

The default stdlib changed to libc++ only on 10.9, so I changed the
proposal to that.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#183 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AA38YGGMJK1LMn4bBPTEuMZ0mKBMSiC5ks5qSYUagaJpZM4JDNsF
.

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

[email protected]

[ihnorton]

Did this letter end up going out? It looks like the plan for 3.7 is currently a "provisional new installer variant for macOS 10.9 and later systems with 64-bit (x86_64)" ...which seems likely to create more confusion:

python/cpython#5448

[ChrisBarker-NOAA]

There was a recently a discussion about this on python dev.

https://mail.python.org/pipermail/python-dev/2018-January/thread.html

But I think it's pretty locked in for 3.7 already.

[jakirkham]

IDK (it’s been a while), but we should send it (possibly again). Are you able to see/edit the document, @ihnorton? Would you be willing to give it a quick review?

[ihnorton]

FWIW I just commented over at cpython#5448, with a few justifications and some stats about low % of users on <10.9.

But I think it's pretty locked in for 3.7 already.

Bummer.

Are you able to see/edit the document

Yes. Just made a few small edits; could potentially add some examples of where this could be a problem for current release-cycle packages on PyPI. Two big ones that people would likely want to use at the same time: Tensorflow (cp36 wheel targets libc++) and matplotlib (cp36 wheel: several backends use C++ and target libstdc++). But given the link posted by ChrisBarker, I guess it's probably too late.

[jakirkham]

Even if they seem committed, I see no harm in sending the email anyways. Worse thing that happens is they say no and continue with their current plan. Outcomes only improve from there.

[jakirkham]

This was addressed a while back. Closing it out. Thanks all for the help 🙂