mkl 11.3.3 vs scipy/numpy

[kmuehlbauer]

As suggested by @jakirkham here is a short summary to the BUG seen in #605.

This came first to my attention through a user request on the wradlib mailing list. A search found conda-forge #605 and this one at ContinuumIO/anaconda-issues#792.

Another issue here ContinuumIO/anaconda-issues#793

Another one with a workaround is here: astropy/ci-helpers#82.

This here is one with some more insight: ContinuumIO/anaconda-issues#753.

Pinging @pelson, @msarahan, @patricksnape, @ocefpaf, @Cadair

[patricksnape]

Just to clarify - this is just to track that fact that at the moment we are working around the broken scipy 0.17.0 build in the conda main repository? There are no action points here because we need Continuum to fix it on their end?

[kmuehlbauer]

@patricksnape This is how I understood @jakirkham. And we have one point of return.

[jakirkham]

Thanks for doing this, @kmuehlbauer.

Just to clarify - this is just to track that fact that at the moment we are working around the broken scipy 0.17.0 build in the conda main repository?

Yes. This is better than tracking it in a bunch of PRs. It is also makes it easier for people proposing recipes to find.

There are no action points here because we need Continuum to fix it on their end?

Well, we need to have this open so that people running into the same problem can find this somewhere. We also want to be able to notify people when it is fixed.

Not mention there is a workaround proposed that we need to use IIRC we need to add mkl 11.3.1 # [win] to the dependencies. That is something we need to list somewhere in the common space so it can be found.

[patricksnape]

Ah ok great - was just wondering if there was anything I could actively do!

[msarahan]

ping @ilanschnell

[jakirkham]

Ah ok great - was just wondering if there was anything I could actively do!

I appreciate that you are always so helpful, @patricksnape. 😄

Maybe if you see someone struggling with this just point them to the issue/workaround.

[jakirkham]

Also, seeing an error on Linux with mkl 1.3.3. Shown below.

Intel MKL FATAL ERROR: Cannot load libmkl_avx.so or libmkl_def.so.

[jakirkham]

Based on this comment, it might be fixed.

[kmuehlbauer]

@patricksnape Could you do your voodoo 😁 with the Dependency Walker again and check this.

[patricksnape]

Hold please...

[patricksnape]

Ok the new MKL build 1 seems to fix the errors about MKL/Intel compiler libraries being missing. Scipy is still incorrectly linked to VS2010 for Python 2.7 though...

I tested Python 2.7/3.4/3.5 and all seem to work.

[kmuehlbauer]

We had issues with scipy on windows lately. @patricksnape could that be caused by this wrong linking?

[patricksnape]

Issues with respect to what? Segmentation faults?

[kmuehlbauer]

Argh, I can't remember the details, but I got a python stacktrace. No segfaults.

[patricksnape]

Probably not - that was probably related to the mkl libraries - but I'd need the stack trace to help 😄

[jakirkham]

Yeah, I think we still have this issue with scipy. Going to just package are own because we want our own anyways.

[jakirkham]

We now have our own scipy on *NIXes! 🎉

Windows will require a build of OpenBLAS, which is in discussion. ( conda-forge/openblas-feedstock#2 ) Though I should add that mkl is the BLAS over there.

Long story short. If you are still pinning things with mkl on Mac or Linux, please try removing them. If you need to keep the pinning for Windows, please try adding a # [win] to select it for Windows only.

Please let me know if you have any issues.

[jakirkham]

I think this issue is resolved. At least there have been no other complaints about MKL that I'm aware of. Going to go ahead and close this. If I'm mistaken, please provide an example of a recent problem and we can reopen it.