Do not link to mkl

[ocefpaf]

Closes #2

Ping @rsignell-usgs

[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.

[leouieda]

@ocefpaf is there a reason that blas was added as a runtime dependency? GMT doesn't really use and from I understand it's only there to make sure GMT isn't tied to MKL.

This is causing some problems for people on OSX with the Accelerate framework. LAPACK is getting conflicts with the conda-forge openblas.

[ocefpaf]

I don't recall the details but the issue was to force the gsl that was linked with openblas.
A lot has changed since then and we should revisit this.

Ping @isuruf who is probably more on top of these than myself. (It is hurricane season and the day job has been quite demanding theses past weeks.)

[isuruf]

GMT is using LAPACK right?

[leouieda]

@ocefpaf thanks for the update! I'm sure you're really busy doing awesome work. Good luck!

GMT is using LAPACK right?

@isuruf it is. This is what is causing problems. On OSX, it's looking at the Accelerate install which complains about openblas.

This is the error that user @egayer got:

dlopen(libgmt.dylib, 6): Library not loaded: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib

Referenced from: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
Reason: Incompatible library version: vecLib requires version 1.0.0 or later, but libopenblas.dylib provides version 0.0.0

[isuruf]

@leouieda, that should be easy to fix. Add -DLAPACK_LIBRARIES=$PREFIX/lib/liblapack${SHLIB_EXT} to the cmake command line.

[leouieda]

@isuruf thanks! I'll try it out.

[leouieda]

But why is "blas" a runtime dependency if GMT is not using it?

Currently, installing GMT forces the install of numpy with blas instead of mkl.
Is there any way around it?