Status of MKL packages in debian - porting to Gentoo

[Mo Zhou]

Hi Aisha,

Debian's MKL package is built from the standalone MKL package instead of
the all-in-one parallel studio package:
https://salsa.debian.org/science-team/intel-mkl/-/blob/master/debian/rules#L10

Specifically, intel has released the standalone MKL package under the
Intel Simplified Software License (ISSL). Maybe the other components in
the parallel studio have different licenses that may complicate the
packaging?

As a source-based distribution, adding mkl development files into
the blas/lapack switch mechanism may cause problems. As the mkl-rt
package contains only runtime libraries, it makes the packaging easier
due the smaller number of files to deal with.

libmkl_rt.so has no soname, and Intel Simplified Software License
prohibits modification to these binary blobs. As a result, if we point
libblas.so -> libmkl_rt.so, once we `gcc foobar.c -lblas`, `readelf
a.out` will show that `a.out` needs `libmkl_rt.so` instead of
`libblas.so.3`, which breaks the blas/lapack switch.


On Sat, Oct 24, 2020 at 09:49:06AM -0400, Aisha Tammy wrote:
> Hello,
> 
> I am writing this email because I am currently working on cleaning up the intel
> 
> packages in gentoo and was asking for details on how the debian packages are
> made.
> 
> Specifically I was wondering on which binary sources are used for creating the
> packages
> 
> There seem to be multiple versions and splits of software from intel.
> 
> The gentoo mkl-rt package was originally made by Mo Zhou, who used continuum
> sources
> 
> as the binary base. I am not sure how continuum builds its packages.
> 
> genoo has another tree at gentoo science, which uses intel parallel studio as
> the binary
> 
> base and then builds sub packages from that, like the icc, ifc, mkl packages.
> 
> Now there are 3 diferent versions of parallel studio - composer, professional
> and cluster.
> 
> The details about the differences between them are not well documented and it
> is possible
> 
> that mixing them together is going to be a problem (I am not sure).
> 
> So it would be nice to know which ones are used in your packages, so that we
> may follow
> 
> suite to make things a bit uniform across platforms.
> 
> 
> Thanks a lot,
> 
> Aisha
> 

> -- 
> debian-science-maintainers mailing list
> debian-science-maintainers at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers