openblas: use default make target

[haampie]

Running make libs && make netlib && make shared causes the ar
commands two run twice, which is surprisingly slow.

The reason we didn't run just make was because it builds and runs tests
unconditionally, and that sometimes broke. I think if it's broken then the
underlying problem should be fixed.

[mathomp4]

I think I'm fine with this. @martin-frbg any objections from the OpenBLAS side?

[martin-frbg]

No objection, totally agree with haampie here - and if absolutely necessary, you could feign CROSS=1 to prevent running of the tests

[mathomp4]

No objection, totally agree with haampie here - and if absolutely necessary, you could feign CROSS=1 to prevent running of the tests

@martin-frbg What exactly does CROSS=1 do? Maybe if it's safe we could add it to this PR.

[martin-frbg]

Normally it signifies cross-compilation, but the main point of doing so is actually to tell the build system that it cannot run target code (like the tests) on the build host. You'd need to re-specify the compiler as HOSTCC though, so that it can build the "getarch" helper program for picking parameters from param.h ... maybe a separate NO_TESTS option would be in order - but OTOH I really do not want packagers to skip tests and potentially distribute broken builds ...

[haampie]

We could consider that as a second-best option when the next person reports test failures :)

[haampie]

@spackbot run pipeline

[spackbot-app]

I've started that pipeline for you!

[paulgessinger]

I think this broke the build on macOS again. I haven't investigated yet, but I'm getting errors like

> Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at (1) [-Wconversion]
> ld: warning: ignoring duplicate libraries: '-lgfortran'
  ld: library 'gfortran' not found
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> make[1]: *** [Makefile:466: test_bgemv] Error 1
> make: *** [Makefile:176: tests] Error 2
  Command exited with status 2:

[paulgessinger]

@haampie root cause seems to be that on macos i'm using clang for c/c++ and gfortran, and openblas' test executables are not set up to receive the right linker flags.

[paulgessinger]

Adding CROSS=1 does not fix this (@martin-frbg), the unit test executables (I think) seemingly unconditionally add -lgfortran which I think the clang linker cannot resolve.

What's the recommended fix?

[haampie]

@paulgessinger can you make an issue upstream and share the full log and system info?

[paulgessinger]

@haampie sure: OpenMathLib/OpenBLAS#5795

[paulgessinger]

@haampie I have this patch here #4656 which applies OpenMathLib/OpenBLAS#5796 to 0.3.32 and fixes the issue for me. Let me know what you think!

[martin-frbg]

I wonder if this isn't just your build environment missing an LD_LIBRARY_PATH pointing to your homebrew lib directory

[paulgessinger]

I don't think setting LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH) is meant for this. Especially in macOS it's strongly discouraged I believe.

[mathomp4]

Yeah, I just looked and I build openblas on my Macs with ~dynamic_dispatch build_system=cmake

I'm not sure why anymore. Just sort of have accumulated those...

[paulgessinger]

I'll try using the CMake. In any case, the PR I put in for the make file build upstream should ultimately fix this.

[martin-frbg]

Okay, thanks. I've read up on MacOS' use of absolute paths in linking now, and why LD_LIBRARY_PATH is a bad idea.