This is the current state of OpenBLAS library naming for the pkgsrc
packages (NetBSD and cross-platform).

The idea is to be able to

1) be able to have a stable library name to expect from the build
2) install multiple variants next to each other (single-threaded, parallel)

For this, the new switch FIXED_LIBNAME is introduced. The build uses

make FIXED_LIBNAME=1 LIBNAMESUFFIX=openmp

In the case of 64 bit indices, it uses

make FIXED_LIBNAME=1 LIBNAMESUFFIX=openmp  INTERFACE64=1 LIBSOBASENAME=openblas64

This results in what I assumed to be the intention of the name variables to
begin with, namely primary predictable library names like

libopenblas_openmp.so
libopenblas64_openmp.so

(As pkgsrc keeps a list of expected file names resulting from a build on the user
machine, too funky names with CPU model in there and symlinks are too funky.)

I see that the naming scheme of the 64 bit indices lib is still under discussion, along
with symbol suffix. So far, we use the names without renamed symbols. They are
all installable at the same time and user software can choose which one to use, also
using the pkg-config file (which could be handled more elegantly). Without an established
convention, I didn't think like we should make the call. Depends on what downstream
packages use at some point.

I don't say that I do not cause more mess than necessary, or that I fully understand
the already pesent mess. Just throwing this suggestion out there. Maybe my the
FIXED_LIBNAME switch or something along that can be included. Or we work out
something better that fulfills the demands of a pkgsrc installation.

See the github mirror of pgksrc for the patches in use.

https://github.com/NetBSD/pkgsrc/tree/trunk/math/openblas
https://github.com/NetBSD/pkgsrc/tree/trunk/math/openblas64
https://github.com/NetBSD/pkgsrc/tree/trunk/math/openblas_openmp
https://github.com/NetBSD/pkgsrc/tree/trunk/math/openblas64_openmp
https://github.com/NetBSD/pkgsrc/tree/trunk/math/openblas_pthread
https://github.com/NetBSD/pkgsrc/tree/trunk/math/openblas64_pthread

Also, I hope I didn't break any other configuration.

And, lastly, one idea: If we settle on OpenMP always and the ILP64 symbols with suffix, we
could just get away with building _one_ libopenmp.so (with libtool versioning, perhaps,
libopenblas.so.0.4.33 and symlinks …). That would also be great and lots of
Makefile machinery could go. Until then, please consider my hack on top;-)

fix shared and tests prereqs

* Add C conversions of the CBLAS tests for NOFORTRAN=1 builds

* Enable CTEST without Fortran and fix passing of BUILD_vartype options to exports/gensymbol

* Add C equivalents of the Fortran routines from Reference-LAPACK as fallbacks, and C_LAPACK variable to trigger their use

gcc also supports -O, -Og and -Os as optimization flags.
They may be given on the make command-line by users.

For the calculation of LAPACK_NOOPT, all such flags should be considered.

Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
[Retrieved from:
https://git.buildroot.net/buildroot/tree/package/openblas/0003-Makefile-also-consider-Os-when-determining-LAPACK_NO.patch]
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

OpenBLAS allows users to specify `FFLAGS` and then uses `override` to append additional
options. However, without such an override in lapack's make.inc, lapack would use the external
FFLAGS, rather than the ones being computed by OpenBLAS. For example the `DEBUG=1` flag
would not apply to LAPACK code. This is all a bit messy but forced by the integration with netlib
lapack. Note that `CFLAGS` already has this override for the same reason. It is possible that
other variables here should have a similar override, but I think for most of the other ones, OpenBLAS's
build system does not append to the flags passed in by the user.

fixes #2552

There is no difference in the way libnames are handle between FreeBSD
and linux or sunos. FreeBSD and DragonFly prefers having sonames as well

related to #2526

Fix use of make vs $(MAKE) in building lapack-testing

[Description]: check the compiler version and show the detail info

Broke lapack-testing on BSD as their default "make" does not support GNU Makefile syntax

[Description]:add c/fortran compiler version information in final note

* Update make.inc entries for LAPACK 3.9.0

Reference-LAPACK PR 347 changed some variable names and relative paths

* Update LAPACK to 3.9.0

* Add new functions from LAPACK 3.9.0

* Add new functions from LAPACK 3.9.0

* Restore LOADER command 

as it makes it easier to specify pthread as needed

* Restore LOADER

* Restore EIG/LIN prefixes in cmdbase

* add binary path to lapack_testing.py call

* Restore OpenMP version check

* Restore OpenMP version check

* Restore fix for out-of-bounds array accesses

from #2096

Thread safety tester using C++11 threading (cleaned history)

to avoid surprises from defining either as zero. Fixes #2035 by addressing some concerns from #1422

Handle conflicting usage of ARCH in at least some BSD environments

in case a conflicting setting of ARCH (for architecture) gets pulled in from the environment
(originally suggested by dloghin in #1753)

partial fix for #1574 - the problem with lapack_testing.py looks like an upstream bug

With this change, OpenBLAS builds and all tests pass on OpenBSD 6.2
using Clang. Tested on x86-64 only, with and without DYNAMIC_ARCH=1.

- retry fortran compiler test with aix-specific option if generic -m32/-m64 fails
- pass any custom ARFLAGS to lapack
- no addition of -m32/-m64 to the CFLAGS and FFLAGS on AIX