rust-math / intel-mkl-src Goto Github PK

I am running into the following issue when trying to build intel-mkl-src (via ndarray & blas-src).
This may be related to #114 , though the error is a little different.

error: failed to run custom build command for `intel-mkl-src v0.5.0`

Caused by:
  process didn't exit successfully: `C:\[...]\target\debug\build\intel-mkl-src-18ed1b0825c7f523\build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-env-changed=MKL_DYNAMIC_LP64_IOMP_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=MKL_DYNAMIC_LP64_IOMP_STATIC
  cargo:rerun-if-env-changed=MKL_DYNAMIC_LP64_IOMP_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=MKL_DYNAMIC_LP64_IOMP_STATIC
  cargo:rerun-if-env-changed=MKL_DYNAMIC_LP64_IOMP_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at C:\Users\craig\.cargo\registry\src\index.crates.io-6f17d22bba15001f\intel-mkl-src-0.5.0\build.rs:35:44:
  Failed to downalod Intel-MKL archive: Custom { kind: Other, error: TarError { desc: "failed to iterate over archive", io: Custom { kind: Other, error: "Unknown frame descriptor" } } }

Runtime error of STATUS_DLL_NOT_FOUND occurs for iomp targets:

##[warning]   Compiling intel-mkl-sys v0.2.0-alpha.0 (D:\a\intel-mkl-src\intel-mkl-src\intel-mkl-sys)
    Finished test [unoptimized + debuginfo] target(s) in 3m 08s
     Running target\debug\deps\intel_mkl_sys-d6a75171bad72c77.exe
error: test failed, to rerun pass '--lib'
##[error]test failed, to rerun pass '--lib'
Caused by:
  process didn't exit successfully: `d:\a\intel-mkl-src\intel-mkl-src\target\debug\deps\intel_mkl_sys-d6a75171bad72c77.exe` (exit code: 0xc0000135, STATUS_DLL_NOT_FOUND)
##[error]The process 'C:\Rust\.cargo\bin\cargo.exe' failed with exit code 3221225781

#48 (comment)

Intel MKL SDK includes static libraries (*.a)
https://software.intel.com/content/www/us/en/develop/tools/math-kernel-library/choose-download/linux.html

TODO

• Detect installed static libraries using pkg-config #35
• Package static libraries and upload to AWS S3
  • packaging #39 #44
  • downloading #43
  • uploading (done by aws-cli, automation -> #41 )
• Add static option in intel-mkl-src, download if necessary
  • Linux #45
  • Windows #48
  • macOS

Hi! First off, great library/project, awesome work.

I'm writing with an issue we recently observed - it's an issue related to an older version of this library (0.7.0); the dependency considered is as follows:

intel-mkl-src = {version= "0.7.0", default-features = false, features=["download", "mkl-static-lp64-seq"]}

What happens is the cargo build seems to get stuck on step 52, example output

 Compiling intel-mkl-src v0.7.0+mkl2020.1
    Building [========================>  ] 52/55: intel-mkl-src(build) 

This has been taking for hours at this point. Have two questions:

1. Should we migrate to >0.8.0, as it seems if we omit the download flag in dependency, it works (fast).
2. Was there any recent change that caused this behavior for 0.7.0 - would like to better understand this behavior.

Appreciate the help, thanks!

cargo publish yields error:

api errors: max upload size is: 10485760

So, we cannot upload libraries to crates.io.

Possible resolutions

• Git LFS

If not, can you give me access in some way so that I can do some fixes?

Edit: Forked at https://github.com/njaard/mkl-src/

https://github.com/rust-math/intel-mkl-src/runs/7556395253?check_suite_focus=true

Current master cannot build on rustc 1.49.0

I'm trying to get a "hello world" build working on macOS 11.4 with intel-mkl-src as a dependency, and I've installed Intel MKL through the oneAPI graphical installer. I can see that the pkg-config files are installed:

$ find /opt/intel -iname '*.pc'
/opt/intel/oneapi/mkl/2021.3.0/bin/pkgconfig/mkl-static-lp64-seq.pc
/opt/intel/oneapi/mkl/2021.3.0/bin/pkgconfig/mkl-static-ilp64-iomp.pc
/opt/intel/oneapi/mkl/2021.3.0/bin/pkgconfig/mkl-dynamic-ilp64-iomp.pc
/opt/intel/oneapi/mkl/2021.3.0/bin/pkgconfig/mkl-static-ilp64-seq.pc
/opt/intel/oneapi/mkl/2021.3.0/bin/pkgconfig/mkl-dynamic-lp64-iomp.pc
/opt/intel/oneapi/mkl/2021.3.0/bin/pkgconfig/mkl-dynamic-ilp64-seq.pc
/opt/intel/oneapi/mkl/2021.3.0/bin/pkgconfig/mkl-dynamic-lp64-seq.pc
/opt/intel/oneapi/mkl/2021.3.0/bin/pkgconfig/mkl-static-lp64-iomp.pc

However, they appear to be broken / misconfigured somehow?

$ PKG_CONFIG_PATH=/opt/intel/oneapi/mkl/2021.3.0/bin/pkgconfig pkg-config --libs mkl-dynamic-lp64-iomp
Variable 'MKLROOT' not defined in '/opt/intel/oneapi/mkl/2021.3.0/bin/pkgconfig/mkl-dynamic-lp64-iomp.pc'

This, I assume, is why cargo is failing to build intel-mkl-src:

10:18:01 raven:port_mkl_example josephlong
$ export PKG_CONFIG_PATH="/opt/intel/oneapi/mkl/latest//bin/pkgconfig/:$PKG_CONFIG_PATH"

10:18:37 raven:port_mkl_example josephlong
$ cargo test
   Compiling intel-mkl-src v0.6.0+mkl2020.1
error: failed to run custom build command for `intel-mkl-src v0.6.0+mkl2020.1`

Caused by:
  process didn't exit successfully: `/Users/josephlong/devel/port_mkl_example/target/debug/build/intel-mkl-src-bd0310f09c0f5b31/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-env-changed=MKL_DYNAMIC_ILP64_IOMP_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=MKL_DYNAMIC_ILP64_IOMP_STATIC
  cargo:rerun-if-env-changed=MKL_DYNAMIC_ILP64_IOMP_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  Error: No MKL found, and download flag is off.

Here's Cargo.toml... related issue is that I can't seem to specify dynamic on macOS and static elsewhere, hence commented lines... suggestions there would also be welcome

[package]
name = "port_mkl_example"
version = "0.1.0"
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

# [target.'cfg(not(target_os = "macos"))'.dependencies]
# intel-mkl-src = { version = "~0.6.0", features = ["mkl-static-ilp64-iomp"], default-features = false }

[target.'cfg(target_os = "macos")'.dependencies]
intel-mkl-src = { version = "~0.6.0", features = ["mkl-dynamic-ilp64-iomp"], default-features = false }

For several days now, I get the following error when compiling with linfa 0.7 with intel-mkl backend (see also in CI tests):

> cargo test --all --release --features blas,linfa/intel-mkl-static
   Compiling intel-mkl-src v0.7.0+mkl2020.1
The following warnings were emitted during compilation:

warning: [email protected]+mkl2020.1: "Download Intel MKL archive into D:\rlafage\workspace\egobox\target\release\build\intel-mkl-src-811c06fa5efcefb9\out"

error: failed to run custom build command for `intel-mkl-src v0.7.0+mkl2020.1`

Caused by:
  process didn't exit successfully: `D:\rlafage\workspace\egobox\target\release\build\intel-mkl-src-0a864131c98c1eb7\build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-env-changed=MKL_STATIC_LP64_SEQ_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=MKL_STATIC_LP64_SEQ_STATIC
  cargo:rerun-if-env-changed=MKL_STATIC_LP64_SEQ_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=MKL_STATIC_LP64_SEQ_STATIC
  cargo:rerun-if-env-changed=MKL_STATIC_LP64_SEQ_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-pc-windows-msvc
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_pc_windows_msvc
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:warning="Download Intel MKL archive into D:\rlafage\workspace\egobox\target\release\build\intel-mkl-src-811c06fa5efcefb9\out"

  --- stderr
  thread 'main' panicked at D:\rlafage\.cargo\registry\src\index.crates.io-6f17d22bba15001f\intel-mkl-tool-0.3.2+mkl2020.1\src\download.rs:38:28:
  called `Result::unwrap()` on an `Err` value: Error { description: "Timeout was reached", code: 28, extra: Some("Failed to connect to s3-ap-northeast-1.amazonaws.com port 443 after 168370 ms: Couldn't connect to server") }
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Release note generator of GitHub becomes mature.
https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository

I am using NDArray Linalg (https://github.com/rust-ndarray/ndarray-linalg) with intel-mkl-static feature. It is working in msvc toolchain perfectly.

However, when I switch to GNU toolchain, I am getting below error,

could not find native static library `mkl_intel_lp64`, perhaps an -L flag is missing?

Any idea why?

This crate depends on openssl-sys, which requires system installation of libssl-dev (or something similar). This is completely silly for crate providing math.

Related #55 #42

Since Intel MKL is licensed by ISSL which allows redistribution, I redistribute them on AWS S3 for download feature. This S3 bucket can be readable from anyone, but writable only by me (@termoshtt). This prevents other developers from maintaining this crate. AWS S3 allows to give writable authority to other developers through IAM, but I do not want to manage them.

I am planning to create a group for managing this repository on GitHub, and hope to sync its authority for MKL binary re-distribution. After some survey for GitHub package and release, GitHub package looks incompatible for this use, and GitHub release assert looks a good option. For example llvm-project distributes ~300MB files in its release page.
https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.1.0

If you want to join the new team https://github.com/orgs/rust-math/teams/intel-mkl-src-maintainers , please let me know.

As #36 (comment), pkg-config setting of official apt/yum repository is broken.

TODO

• Create test container for apt/yum installation like #36
• Seek mkl using environment variable e.g. MKLROOT which specify where the MKL is installed

I'd like to use this crate, as it integrates well with nalgebra-lapack, and I like the way the different src crates work together.

However, at the moment, it's a bit of a showstopper that the crate downloads an enormous proprietary framework from a random AWS URL, both for security reasons as well as bandwidth considerations, and last but not least stability: what happens if you are no longer able to host the binaries?

Would you be willing to making this behavior opt-in, and instead to use installed MKL libs by default? I'm sorry if this has been discussed before, I could not find any indication of this.

Current MKL update procedure is following:

1. Update system MKL using package manager (pacman on ArchLinux, or manually on Windows)
2. Create packages (mkl-*.tar.zst) using intel-mkl-tool
3. Upload them onto AWS S3 ( this may be merged into 2. #41 )
4. Update hard coded version of MKL

However, I have no macOS machine, and procedure 1 is hard for me.

https://github.com/termoshtt/ocipkg
ocipkg is designed to use OCI registry (i.e. GitHub Container Registry) for binary distribution

https://www.intel.com/content/www/us/en/develop/documentation/onemkl-developer-reference-c/top/sparse-solver-routines/onemkl-pardiso-parallel-direct-sparse-solver-iface.html

The Intel® oneAPI Math Kernel Library PARDISO package is a high-performance, robust, memory fficient, and easy to use software package for solving large sparse linear systems of equations on shared memory multiprocessors.

Related: #52

https://github.com/rusoto/rusoto

intel-mkl-src backet on S3 will be following directory structure

• Linux
  • 2020.1
    • mkl-dynamic-lp64-iomp.tar.zst
    • mkl-static-lp64-iomp.tar.zst
    • (others archives)
  • (other versions)
• Windows
  • 2020.1
    • mkl-dynamic-lp64-iomp.tar.zst
    • (others)
  • (other versions)
• macOS
  • 2020.1
    • mkl-dynamic-lp64-iomp.tar.zst
    • (others)
  • (other versions)

These archives can be created by intel-mkl-tools package, and uploaded manually by aws s3 sync command. I'd like to upload them by e.g. intel-mkl-tools package --upload

intel-mkl-sys crate introduced in #26 contains FFI for PRNG in MKL
https://software.intel.com/en-us/onemkl-developer-reference-c-random-number-generators

Hi, I just found intel-mkl-tool may not work well with libiomp5.so when Intel MKL suite is not installed to /opt/intel.

If I didn't misunderstand the code, the function seek_directory just finds the paths of MKL libraries with given root_dir. When Intel MKL suite is installed to /opt/intel, seek_directory just can find the correct path of libiomp5.so since Library::new() already includes /opt/intel, and everything works well. However, libiomp5.so doesn't lie in MKLROOT, but in oneapi/compiler/${version}/${platform}/compiler/lib, leading to the failure.

There might be two possible solution:

• I found intel-mkl-tool used pkg-config to find alternative of MKLROOT, but it may be easier to parse the output of pkg-config --libs mkl-dynamic-lp64-iomp, since the corresponding .pc files are provided by Intel and can work as expected in most environments;
• For the case that pkg-config is not found, just add an additional root_dir=$MKLROOT/../../ and use seek_directory to find the right path. There may be some issues when multiple versions of oneAPI is installed to one root_dir, but this can be resolved by using the same version of MKL and compiler. It seems you've implemented Library::version function but not used it, so here comes the role of it.

I can make an PR to fix this but it would be better to fix it by the author since my coding style may not match this repo very well....

download feature which download MKL binaries from AWS S3 has been removed in 0.8.0 release.

Does anybody have a summary of the license impacts with respect to MKL licensing on static vs dynamic linking?

Some clauses:

You may use and redistribute the software (the“Software”), without modification
No reverse engineering, decompilation, or disassembly of this Software is permitted.

My question: does static linking constitute "disassembly" or "modification"?

I figured this might be worth updating the readme or adding a wiki page for. At the very least this should be asked & answered.

links:

• the license text (pdf): https://www.intel.com/content/dam/develop/external/us/en/documents/intel-simplified-software-license.pdf
• fairly useless intel.com FAQ: https://www.intel.com/content/www/us/en/developer/articles/tool/onemkl-license-faq.html
• somebody else on intels forums spooked about this clause (for dynamic linking): https://community.intel.com/t5/oneAPI-Registration-Download/MKL-License-Limited-patent-license/td-p/1285345

Dear team,

It is a stupid question but it seems intel-mkl can also be run on AMD CPUs with the MKL_DEBUG_CPU_TYPE=5 option according to testings here: https://www.pugetsystems.com/labs/hpc/How-To-Use-MKL-with-AMD-Ryzen-and-Threadripper-CPU-s-Effectively-for-Python-Numpy-And-Other-Applications-1637/#Threadripper3960x,Ryzen3900XandXeon2175WperformanceusingMKL,MKL_DEBUG_CPU_TYPE=5andOpenBLASforaPythonnumpy\

I am wondering whether this is the same here to use it. Without the option, it seems very slow. I will have more testings added after running on an AMD CPU.

Thanks,

Jianshu

Using large web framework is flexible and feature rich, but is somehow expensive in disk space. My matrix calculation program compiles intel-mkl-src whick requires a huge web framework by extern crate reqwest (code), resulting in eaten up almost 3.44GB of disk space only to calculate one dot result of two matrices. If we consider light weight framework e.g. curl, we can get rid of large target folder space cost and download the source faster (rather than GBs of target + source size).

PR for lapack-sys does not pass the CI since intel-mkl-src does not support macOS
blas-lapack-rs/lapack-sys#8

TODO

• Add macOS target in CI
• Pass test for macOS

I've raised a similar concern before in #29. The situation is much improved now since a local library is sought first, and there is a download feature which controls whether or not MKL might be downloaded if none was found.

However, because the feature is default, it means that if any library depending on intel-mkl-src fails to set default-features = false, the download option will be enabled, and there is no way to turn it off (besides patching all dependencies that use it). There are several reasons why downloading is problematic or undesirable:

1. The Intel MKL binaries can be pretty huge (potentially hundreds of megabytes). I would not expect simply adding a dependency to Cargo.toml could result in hundreds of megabytes in bandwidth for a single dependency. This is problematic for people on limited connections (slow / capped / mobile).
2. It represents a potentially very dangerous attack vector. If someone with malicious intent would gain control of intel-mkl-src and modified the source code for evil purposes, in this case there would be a record of the release, and it would be detectable by inspecting the source code uploaded to crates.io. However, by just downloading a binary blob off of AWS there are no guarantees that a malicious actor hasn't switched out the binaries with malicious code. This would be much harder to detect.
3. The feature only works for as long as whoever foots the bills for AWS is still paying. This might be somewhat mitigated by moving to GitHub Releases however, (as discussed in #58) and you can anyway install system libraries.

My suggestion is as follows:

1. Make download non-default.
2. Encourage library authors to not enable it.
3. Instead, encourage end users (i.e. those producing a binary application) that want the automatic download to turn on the feature in their binary crate instead.

I would love to hear your thoughts. For us this is currently a blocker from possibly diverting our attention from our own mkl-sys crate (not on crates.io) to instead contributing to this crate. I think for the sake of the ecosystem it would be great if we could consolidate efforts here.

Hi I'm trying to get a simple ndarray setup using BLAS on a HPC cluster working with intel-mkl as the BLAS library. Unfortunately even a bare bones setup is unable to find the proper library, and even a simple binary just doing a matrix multiplication fails to build. After loading the proper modules and checking that the intel-mkl library is accessible (I can navigate through the mkl folders, I can find blas libraries, and $MKLROOT points to the proper path and so does pkg-config -- variable=prefix mkl-static-lp64-seq) I try to build a basic binary with the following Cargo.toml:

[package]
name = "tester"
version = "0.1.0"
edition = "2021"

[dependencies]
ndarray = {version = "0.15.0", features = ["blas"]}
blas-src = {version = "0.8.0", features = ["intel-mkl"]}
intel-mkl-src = {version = "*"}

and I get a bunch of errors like the following:
/gpfs/fs1/home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/zstd-sys-1.4.18+zstd.1.4.7/zstd/lib/common/xxhash.c:85: undefined reference to `_intel_fast_memcpy'
with the following "help"

collect2: error: ld returned 1 exit status

  = help: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `intel-mkl-src` due to previous error

I know that the HPC FAQ specifies that a -mkl flag should be passed to gcc if linking against intel-mkl with c++ but I was not sure how to add that into here or if it would be necessary. Any help would be appreciated.

Error detailed in repo of failing crate
containers/oci-spec-rs#179

I propose maintaining all BLAS- and LAPACK-related crates under a separate organization dedicated to this particular purpose. I’ve already created an organization called blas-lapack-rs, BLAS and LAPACK for Rust, and moved all relevant crates from Stainless Steel to that organization.

What do you think about moving intel-mkl-src to blas-lapack-rs? I intend to make changes in order to make this package look similar to the rest, but you will retain full control over the repository and the crate on crates.io.

For target_os="windows" target_arch="x86" there's no configuration at all.

Happy to add manually if you have the appropriate tar.zst in the s3 bucket.

Thanks

Following the release of anyhow 1.0.49, I get the following compilation error:

  
...
   Compiling ndarray-linalg v0.14.1
   Compiling zstd v0.5.4+zstd.1.4.7
   Compiling intel-mkl-tool v0.2.0+mkl2020.1
error[E0532]: expected tuple struct or tuple variant, found function `Ok`
  --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/intel-mkl-tool-0.2.0+mkl2020.1/src/entry.rs:75:16
   |
75 |         if let Ok(dir) = std::env::var("OUT_DIR") {
   |                ^^ not a tuple struct or tuple variant
   |
help: consider importing one of these items instead
   |
1  | use core::result::Result::Ok;
   |
1  | use std::result::Result::Ok;
   |
...

It seems like the new Ok() function introduced in anyhow breaks the code. see anyhow 1.0.49 release. Pinning anyhow to 1.0.48 solves the problem.
@dtolnay, to also bring this to your attention.

MKL provides libmkl_gnu_thread.a, but currently there is no way to use it from this crate

Switch to 2019.5.x versioning to clarify what version of Intel-MKL is used.

From rust-ndarray/ndarray#415

VM Mathematical Functions
https://software.intel.com/en-us/mkl-developer-reference-c-vm-mathematical-functions

This section describes VM functions that compute values of mathematical functions on real and complex vector arguments with unit increment.

I have installed intel mkl and verified it can be found with pkg-config, as running pkg-config --variable=prefix mkl-static-lp64-seq results in the output /opt/intel/oneapi/mkl/latest/lib/pkgconfig/../.. . However, when running a barebones binary setup with the following lines in my Cargo.toml:

ndarray = {version = "*", features = ["blas"]}
ndarray-linalg = {version = "*", git="https://github.com/matthagan15/ndarray-linalg.git", branch="stable_expm"}
blas-src = {version = "*", features = ["intel-mkl"]}

I get the following output when trying to build a tester binary:

error: linking with `cc` failed: exit status: 1
  = note: Undefined symbols for architecture x86_64:
            "_cblas_cgemm", referenced from:
                ndarray::linalg::impl_linalg::mat_mul_impl::ha9237a4a1bfa42c4 in expm_test-0790de8f547e9cbd.4kiz8b0v0q92ql7g.rcgu.o
            "_cblas_ddot", referenced from:
                ndarray::linalg::impl_linalg::_$LT$impl$u20$ndarray..ArrayBase$LT$S$C$ndarray..dimension..dim..Dim$LT$$u5b$usize$u3b$$u20$1$u5d$$GT$$GT$$GT$::dot_impl::h6cc7f6400866deb3 in expm_test-0790de8f547e9cbd.4unh5nyr6the737r.rcgu.o
            "_cblas_dgemm", referenced from:
                ndarray::linalg::impl_linalg::mat_mul_impl::ha9237a4a1bfa42c4 in expm_test-0790de8f547e9cbd.4kiz8b0v0q92ql7g.rcgu.o
            "_cblas_dgemv", referenced from:
                ndarray::linalg::impl_linalg::general_mat_vec_mul_impl::hb2c5d2f9aa4fb833 in expm_test-0790de8f547e9cbd.4kiz8b0v0q92ql7g.rcgu.o
            "_cblas_sdot", referenced from:
                ndarray::linalg::impl_linalg::_$LT$impl$u20$ndarray..ArrayBase$LT$S$C$ndarray..dimension..dim..Dim$LT$$u5b$usize$u3b$$u20$1$u5d$$GT$$GT$$GT$::dot_impl::h6cc7f6400866deb3 in expm_test-0790de8f547e9cbd.4unh5nyr6the737r.rcgu.o
            "_cblas_sgemm", referenced from:
                ndarray::linalg::impl_linalg::mat_mul_impl::ha9237a4a1bfa42c4 in expm_test-0790de8f547e9cbd.4kiz8b0v0q92ql7g.rcgu.o
            "_cblas_sgemv", referenced from:
                ndarray::linalg::impl_linalg::general_mat_vec_mul_impl::hb2c5d2f9aa4fb833 in expm_test-0790de8f547e9cbd.4kiz8b0v0q92ql7g.rcgu.o
            "_cblas_zgemm", referenced from:
                ndarray::linalg::impl_linalg::mat_mul_impl::ha9237a4a1bfa42c4 in expm_test-0790de8f547e9cbd.4kiz8b0v0q92ql7g.rcgu.o
            "_dlange_", referenced from:
                _$LT$lax..opnorm..OperatorNormWork$LT$f64$GT$$u20$as$u20$lax..opnorm..OperatorNormWorkImpl$GT$::calc::h89516ca1d11135c0 in liblax-5a109cea01c73e90.rlib(lax-5a109cea01c73e90.lax.dffd72c6-cgu.13.rcgu.o)
            "_zgeev_", referenced from:
                _$LT$lax..eig..EigWork$LT$num_complex..Complex$LT$f64$GT$$GT$$u20$as$u20$lax..eig..EigWorkImpl$GT$::new::h1a01750a222090a0 in liblax-5a109cea01c73e90.rlib(lax-5a109cea01c73e90.lax.dffd72c6-cgu.8.rcgu.o)
                _$LT$lax..eig..EigWork$LT$num_complex..Complex$LT$f64$GT$$GT$$u20$as$u20$lax..eig..EigWorkImpl$GT$::calc::h9f18ee0eac259059 in liblax-5a109cea01c73e90.rlib(lax-5a109cea01c73e90.lax.dffd72c6-cgu.8.rcgu.o)
            "_zgetrf_", referenced from:
                _$LT$num_complex..Complex$LT$f64$GT$$u20$as$u20$lax..solve..LuImpl$GT$::lu::h30148031dbbcc1c8 in liblax-5a109cea01c73e90.rlib(lax-5a109cea01c73e90.lax.dffd72c6-cgu.4.rcgu.o)
            "_zgetri_", referenced from:
                _$LT$lax..solve..InvWork$LT$num_complex..Complex$LT$f64$GT$$GT$$u20$as$u20$lax..solve..InvWorkImpl$GT$::new::h0035c072560db9c9 in liblax-5a109cea01c73e90.rlib(lax-5a109cea01c73e90.lax.dffd72c6-cgu.15.rcgu.o)
                _$LT$lax..solve..InvWork$LT$num_complex..Complex$LT$f64$GT$$GT$$u20$as$u20$lax..solve..InvWorkImpl$GT$::calc::h95f3108d9f561f38 in liblax-5a109cea01c73e90.rlib(lax-5a109cea01c73e90.lax.dffd72c6-cgu.15.rcgu.o)
            "_zlange_", referenced from:
                _$LT$lax..opnorm..OperatorNormWork$LT$num_complex..Complex$LT$f64$GT$$GT$$u20$as$u20$lax..opnorm..OperatorNormWorkImpl$GT$::calc::hd0a09b3056028cc0 in liblax-5a109cea01c73e90.rlib(lax-5a109cea01c73e90.lax.dffd72c6-cgu.13.rcgu.o)
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)


warning: `expm_test` (bin "expm_test") generated 2 warnings
error: could not compile `expm_test` due to previous error; 2 warnings emitted

I want to use mkl_sparse_* functions but I found that intel-mkl-sys only bindgened mkl_vml.h and mkl_vsl.h.

What's the purpose that not bindgen the whole mkl.h in wrapper?
May I create a PR to fix it?

• About pkg-config
  • Fix in docker image #36
  • apt/yum official installer
• Explicit detection #37

I realize this may be a Bad Idea because the entire distribution is 20+ GB (!) but it seems Intel wants to make oneAPI the future of the MKL. Perhaps that could be used instead of the current setup? It seems when I go to download it, the link is https://registrationcenter-download.intel.com/akdlm/irc_nas/17453/w_BaseKit_p_2021.1.0.2664_offline.exe (presumably this changes from time to time based on versions, I'm not sure if old versions stay up). Or perhaps there could be a system by which you could have a "system" mkl install... (aka the user downloaded and installed oneAPI already)

I'm getting "Intel MKL ERROR: Parameter 11 was incorrect on entry to cblas_dgemm." I'm guessing that this is due to using version 2021.1 instead of 2020.1 but I can't seem to find a download for 2020.1 for Windows. For reference I have built ndarray, blas-src, and intel-mkl-src all from the most recent commits.