[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New BLAS/LAPACK system
On 10/14/20 4:22 AM, Dr. Thomas Orgis wrote:
While at that … do we consider such (from my patch for math/octave) as
something for a subsequent stage or should those changes be pushed now?
This is needed to make actual BLAS choice work for several packages.
Without these changes, any lib in some prefernce list will be picked
up, modulated by buildlinks.
1) The openblas packages are now committed, marked only for Linux for
There are some source code issues on NetBSD and some issues with
handling of gfortran dependencies, most of which I think are in gcc.mk
and possibly gfortran.mk. Basically, packages with
USE_LANGUAGES+=gfortran soemtimes add a gcc package dependency, but fail
to set link options the same way as GCC_REQD. I think the cleanest
solution would be to leverage the GCC_REQD code when requiring a gcc
packages for Fortran, rather than maintaining redundant code just for
Fortran. A quicker fix would be simply adding -L and rpath flags to the
gfortran code when it pulls in a gcc package.
This issue might affect other platforms as well, if they use a base cc
and c++ with pkgsrc gfortran. On Linux, C, C++, and Fortran typically
all come from the same place, either the Linux distro's packages or pkgsrc.
I think this needs careful examination, which I won't have time for in
the next month or so.
2) I have not been able to test on Darwin since the gcc packages are not
building on my High Sierra system.
3) The aforementioned gfortran issues are in the way of committing
wip/cblas and wip/lapacke as well. These two packages are not urgently
needed as far as I can tell, so I think we might as well fix the global
Fortran issues before committing them.
4) I think the CONFIGURE_ARGS issues are best tested and committed one
package at a time, now that the BLAS infrastructure is in-place.
Main Index |
Thread Index |