[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Updates about BLAS64


On Thu, Jan 03, 2019 at 03:13:00PM +0100, Drew Parsons wrote:
> I'd say it's more common for non-coinstallable packages to be installed in
> subdirs (e.g. using DESTDIR facilities during configuration and build), and

Theoretically yes, but in fact I don't want to make different variants
co-installable, particularly for BLIS. That's because the co-installbility
would result in 2 levels of alternatives system and make things complicated:

something asks for libblas.so.3
  -> (looking for libblas.so.3 provider)
    -> we found libblis.so.X
      -> (looking for libblis.so.X provider)
        -> we found the real libblis in some subdir.

And I don't know if there is any user who wants to confuse themself
by installing all the variants and got no idea which on earth is
really used when they encountered some threading trouble.

Such threadding trouble happend to OpenBLAS in history.
And mixing the usage of different threading library leads to nightmare.

@Sébastien: What's your opinion at this point? I mean, what if we
are talking about the 6 variants of OpenBLAS?

Of course, BLAS and BLAS64 are co-installable.

> then using alternatives to make the preferred alternative active.
> But I think you already have that with the libblas alternatives.

Under the current layout, I only need to take care of 1 level of
alternatives (libblas.so.3). And there is no alternative mechanism
setup for libblis.so.X since candidates are conflicting with each

Reply to: