[Buildroot] [PATCH 2/5] package/liblapack: add liblapack as virtual package with lapack and clapack as providers.

Thomas De Schampheleire patrickdepinguin at gmail.com
Mon Aug 5 12:30:00 UTC 2019


El sáb., 3 ago. 2019 a las 12:23, Arnout Vandecappelle
(<arnout at mind.be>) escribió:
>
>  Hi Alex, Romain,
>
> On 01/08/2019 23:09, Romain Naour wrote:
> > lapack and clapack are both generating the same liblapack.so but does not have
> > the same symbols. So the run-time is broke. They have to exclude each other.
>
>  We discussed this at the hackaton and reviewed all the options that were
> discussed before on the mailing list, and we concluded that the simplest
> solution is to remove clapack entirely. Everything that uses clapack (i.e.,
> armadillo and numpy) can use lapack as well, as you mention, so the only reason
> to keep clapack would be to support toolchains without Fortran compiler. Most of
> our external toolchains do have Fortran support, and I expect that anybody who
> cares about maths wouldn't mind enabling Fortran in their toolchains.
>
>  If anybody disagrees with that, now is the time to speak up :-)
>

There may be cases where a toolchain is provided by a third-party,
e.g. a silicon vendor like Marvell.
In this case, Fortran is not necessarily provided. Depending on that
third-party, it may or may not be easy to get this fixed.

In our case, we have some boards with a toolchain from Marvell (no
Fortran) and others where we build the toolchains ourselves. In both
cases we have armadillo with clapack. Recently, we wanted to use
openblas, and getting clapack to work as lapack backend for openblas
did not seem to work. So for those boards were it mattered, we enabled
fortran and let openblas use its own lapack implementation. For the
boards with Marvell toolchain, we planned to keep the existing
armadillo+clapack situation.

So removing clapack altogether would not be desirable for that case.

Note also that openblas also has lapack inside its sources. So it
could also a provider for liblapack in the case of a virtual-package
situation.

I searched but could not find extensive discussion on the mailing list
regarding this topic.
What is the actual problem with introducing a virtual-package?

Thanks,
Thomas


More information about the buildroot mailing list