This PR patches the f_check scripts to detect the ifort compiler. With
out this, the value of F_COMPILER is G77 which causes the link phase to
use icc rather than ifort, resulting in missing libifcore.
* Add mixed clang/ifort build on OSX to the Azure CI config based on https://github.com/oneapi-src/oneapi-ci
(and remove debugging tools from the clang+gfortran job)
* Remove extraneous libgfortran dependency of ifort builds
* remove FEXTRALIB from link line of shared library as ifort keeps track of dependencies (and they are different for a .dylib than what f_check got for an executable)
Auto-add "-fno-second-underscore" option to make LAPACKE compile (as it calls LAPACK functions that may have gotten a second underscore added otherwise). Also support -R for rpath when parsing compiler directives in f_check
1. the already deprecated -openmp option was removed in 2018, switch to -fopenmp
2. add leading blank in search for "zho_ge__" symbol to work around misleading tags in the 2018 assembly
Expected to fix#1548
- 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
Without proper recognition of gfortran versions such as
> GNU Fortran (GCC) 4.9.x 20150123 (prerelease)
OpenBLAS assumes the presence of the G77 compiler. Consequently,
`-lgfortran` is missing from the pkg-config file.
The aforementioned compiler is the gfortran compiler in the Android repo
in a commit tagged as `ndk-r14`, cf. Paul Mustière's gfortran build
instructions for Android at https://github.com/buffer51/android-gfortran
On FreeBSD, passing extra options to `which` causes it to report a non-zero status:
```
$ which gfortran48 -m64
/usr/local/bin/gfortran48
$ echo $?
1
```
```
$ which gfortran48
/usr/local/bin/gfortran48
$ echo $?
0
```