Use the toolchain to build

[jakirkham]

Fixes #39

So, matplotlib was not using the toolchain previously (has been around for quite awhile), but has C++ code. As discussed in this issue ( conda-forge/conda-forge.github.io#183 ), we need to be using libc++ on Mac. However, it appears some shadowing is happening additionally as suggested by this report ( #39 ). This switches matplotlib over to libc++ and thus should resolve these issues.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[jakirkham]

This passes on Travis CI. It is clean of libstdc++ in all builds. Everything is linked to libc++ instead. Some builds use the mkl-linked numpy as it is newer in some case (1.11.0 vs. 1.11.1). Some use our numpy with openblas. Both cases without issues.

[ocefpaf]

Since you guys are set to force numpy+openblas down the stack the only safe solution is to add the toolchain to everything that has numpy x.x and might like to libstdc++ and ensure that the toolchain won't break any of them as it did with gdal...

The alternative that I am proposing is to pull numpy+openblas from the main channel. Leave it in the a dev channel. And implement it once we are actually ready. By ready I mean: proper solution for libgfortran on OS X. Proper linking to libc++ everywhere. Proper and tested toolchain, or copy and paste of the only the necessary, flags in the stack.

What I am proposing is an incremental way forward that will ensure stability of the stack.

Ping: @pelson, @gillins, @msarahan, and @kmuehlbauer.

[jakirkham]

How are you guys using C++ in matplotlib? Are you using C++ to interact with other libraries/providing it as an API or is it just used internally? If the latter, there is no need to worry about what other things are using for C++ as it has no effect on matplotlib.

[pelson]

I have merged this, as I believe it does incrementally improve the current situation (no longer linking to libstdc++). There is a philosophical question which we will be discussing tomorrow as to whether we want to be pulling in the toolchain to automagically set ENV vars, but I do not think the result of that makes any difference to the resulting matplotlib built distribution - which should now be fixed from libstdc++.

[jakirkham]

I have merged this, as I believe it does incrementally improve the current situation (no longer linking to libstdc++).

👍 I assume you are in a better position to answer the above question as well.

There is a philosophical question which we will be discussing tomorrow as to whether we want to be pulling in the toolchain to automagically set ENV vars, but I do not think the result of that makes any difference to the resulting matplotlib built distribution - which should now be fixed from libstdc++.

👍

Though I know I don't have the bandwidth to help keep all those flags straight, which was one of the motivators for creating the toolchain. I think I might need to say one of those things that hardware manufactures say like, "if you build your package in a non-supported configuration, you void your warranty". Sorry, it is a matter of practicalities at this point. I must acknowledge my limits.

Feel free to discuss. Unfortunately, as mentioned on gitter, I won't be able to make it to a meeting tomorrow. I'd request that we hold off on a decision on this important issue until I can be present.

[pelson]

I'd request that we hold off on a decision on this important issue until I can be present.

Perfectly reasonable. Will do.