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?
+CONFIGURE_ARGS+= --with-blas=${BLAS_LIBS:Q}
+CONFIGURE_ARGS+= --with-lapack=${LAPACK_LIBS:Q}
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.
Alrighty then,
Thomas
1) The openblas packages are now committed, marked only for Linux for the moment.
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.
Best, JB