Bug 244296 - math/openblas: Need to resolve conflicts with cblas and lapacke
Summary: math/openblas: Need to resolve conflicts with cblas and lapacke
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-22 01:38 UTC by Jason W. Bacon
Modified: 2020-06-02 07:13 UTC (History)
6 users (show)

See Also:
bugzilla: maintainer-feedback? (phd_kimberlite)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jason W. Bacon freebsd_committer 2020-02-22 01:38:31 UTC
I see that openblas now cannot be installed alongside cblas or lapacke.

This is a big problem for many sites as it means some users cannot install all the dependent software they need side-by-side.  This is especially problematic for multi-user installations such as HPC clusters and lab workstations.

I wonder if we could patch out the bundled cblas and lapacke headers and add cblas and lapacke as dependent ports instead.  They should be compatible, if not identical.

Thanks,

    JB
Comment 1 Thierry Thomas freebsd_committer 2020-02-22 09:26:19 UTC
Another possibility could be to set the default to openblas for as many ports as possible, so that packages won't conflict.

At the moment Mk/Uses/blaslapack.mk default to netlib, but we can change that. We could also modify it to handle cblas, with an extra argument.
Comment 2 Jason W. Bacon freebsd_committer 2020-02-22 14:34:02 UTC
(In reply to Thierry Thomas from comment #1)

I think that would be a good idea, though there will always be a need to allow different BLAS/LAPACK implementations to coexist.  For instance, plink2 (https://github.com/outpaddling/freebsd-ports-wip/tree/master/plink2) currently crashes when linked with openblas but works fine with netlib.  Since BLAS is not a bottleneck for this program, there's no reason not to make it available using netlib (which is slow) while we try to diagnose the issue with openblas.

While the various implementations are meant to be fully compatible, the reality is that there will always be bugs and minor differences.  Allowing users to work around them by using another implementation for a while will keep them happy and productive with FreeBSD.

I was planning to save this for a separate conversation, but since we're on the subject of systemic solutions, I'm preparing to commit the work of T. Orgis on an interchangeable BLAS interface for pkgsrc:

https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob;f=mk/blas.buildlink3.mk;h=e09d41644b7d6e3eb183b03b8a40604ef632efe4;hb=HEAD

This system allows the sysadmin to specify one or more preferred BLAS implementations in mk.conf (equiv to make.conf on FreeBSD) and also allows the package maintainer to specify which implementations are acceptable in the package Makefile.

After some extensive discussion, we ended up with a pretty elegant and flexible solution.
Comment 3 Koichiro Iwao freebsd_committer 2020-03-31 04:40:51 UTC
This also affect me.
Comment 4 Koichiro Iwao freebsd_committer 2020-03-31 04:43:43 UTC
math/py-numpy depends on both openblas and cblas. It cannot be installed unless this issue is solved. 
> ===>>> math/py-numpy >> (3)
> 
> ===>>> The following actions will be taken if you choose to proceed:
> 	Install math/py-numpy
>	Install math/cblas
> 	Install math/suitesparse
> 	Install math/openblas
> 
> ===>>> Proceed? y/n [y]
Comment 5 Harry NEWTON 2020-06-02 07:13:49 UTC
Affects me too.  Cannot install numpy or scipy.

Is it related to the changes made for https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243497 ?