Missing LAPACK "testing" symbols

[staticfloat]

The MAGMA project, which provides heterogenous BLAS capabilities, wants to link against a backing BLAS library. Attempting to use OpenBLAS results in errors because symbols such as zqpt01 are not exported from the shared library. Digging into the CMakeLists.txt and Makefiles within lapack-netlib/TESTING/LIN, it looks like these symbols are only linked into the actual testing executables (e.g. xlintst*) and not into libopenblas. Is this intentional? I have no idea of the "standard" BLAS symbol space, but if MAGMA is expecting to find zqpt01 within its BLAS/LAPACK library, it seems to me that perhaps these symbols should be included within the overall library.

[brada4]

It is self-test code, not a library export. It is absent from MKL completely.

[staticfloat]

So you're saying that MAGMA should not be reliant on these symbols, and that the issue is that MAGMA is expecting to find internal testing symbols?

[martin-frbg]

I guess the question is if these functions are named in one of the "official" include files, or if one has to know that they "must be in there somewhere". (They are not, and indeed zqpt01 in particular would be a curious example as it is not a library function at all, but one of the driver routines from the LAPACK linear algebra self-tests. You would not find it in a build of the "netlib" reference implementation either.) Are you sure you built MAGMA correctly ? I do not see any such issue or requirement mentioned on their website.

[brada4]

So you're saying that MAGMA should not be reliant on these symbols, and that the issue is that MAGMA is expecting to find internal testing symbols?

The issue is that they generated cover-all header file from all lapack fortran source files, including obvious testing directories. Even the generic LAPACK from NetLib does not work for them.

[martin-frbg]

The issue is that they generated cover-all header file from all lapack fortran source files, including obvious testing directories.

Is this really what they are doing, or is this pure speculation ? With Julien Langou supposedly part of their team that would be a very surprising mistake to make, and I would expect it to fail with just about any third-party LAPACK. Or do they bring their own modified LAPACK based on netlib (much like OpenBLAS does), and only expect to rely on a third-party BLAS ? (In that case perhaps one should link it against a NO_LAPACK=1 build of OpenBLAS)

[brada4]

The header and link testing python code is theirs. It has no 1:1 counterpart in NetLib LAPACK
Their forums ar full that no lapack.so in Ubuntu is satisfactory and people "go with MKL" instead.
Speculation is that "go with" part is a build that has bad stuff patched out...

[brada4]

With plain grep:
Sort of acceptable use in testing

./testing/testing_zgeqp3_gpu.cpp:                error = lapackf77_zqpt01( &M, &N, &min_mn, h_A, h_R, &lda,
./testing/testing_zgeqp3.cpp:                error = lapackf77_zqpt01( &M, &N, &min_mn, h_A, h_R, &lda,
./testing/lin/magma_z_no_fortran.cpp:double lapackf77_zqpt01( const magma_int_t *m, const magma_int_t *n, const magma_int_t *k,
./testing/lin/Makefile.src:     $(cdir)/zqpt01.f  \
./testing/lin/Makefile.src:   zqpt01.$(o_ext) zqrt01.$(o_ext) zqrt02.$(o_ext) zqrt03.$(o_ext) zqrt11.$(o_ext) \

Then in public-looking API:

./include/magma_zlapack.h:#define lapackf77_zqpt01   FORTRAN_NAME( zqpt01, ZQPT01 )
./include/magma_zlapack.h:double lapackf77_zqpt01( const magma_int_t *m, const magma_int_t *n, const magma_int_t *k,
./tools/magmasubs.py:    ('sqpt01',         'dqpt01',         'cqpt01',         'zqpt01'          ),

I think they could derive lapack API from netlib lapacke.h, and add the testing modules to build of test files in testing/linthe way netlib lapack does, and openblas copies.

[martin-frbg]

Weird. (But I did not see any threads in the magma forum that could be related, concerns seemed to be mostly about specific older versions of CUDA and/or MKL ?)

[JerryChen97]

The actual relevant discussion in the MAGMA forum is the ILP64 name mangling.
I took the suggestion given in the forum discussion and made use of the libopenblas64_.so which is used by Julia, but then came across the qpt problem. After the global name mangling, my ld could not find the qpt functions, which we eventually found not existing in any relevant library. I used to think they might be some missing symbols in LAPACK/OPENBLAS since I noticed in some header file they were defined as lapckf77_zqpt01 (or likewise). But now I realize your argument should be correct and they are just temporary testing functions. Still don't know how to deal with this though...

[martin-frbg]

Given that this does not appear to have come up in "normal" i.e. non-mangled builds, could it be that they already use some (c)make magic to strip out the testing functions, and the ILP64 mangling just manages to foil it ? I do not see why anyone would want the LAPACK test routines to be callable in the library.
(EDIT: a quick grep of at the toplevel makefiles in magma-2.5.2 seems to place these in a separate liblapacktest - see e.g CMakeLists.txt from line 587, which would make a bit more sense ?)

[JerryChen97]

Given that this does not appear to have come up in "normal" i.e. non-mangled builds, could it be that they already use some (c)make magic to strip out the testing functions, and the ILP64 mangling just manages to foil it ? I do not see why anyone would want the LAPACK test routines to be callable in the library.
(EDIT: a quick grep of at the toplevel makefiles in magma-2.5.2 seems to place these in a separate liblapacktest - see e.g CMakeLists.txt from line 587, which would make a bit more sense ?)

That sounds good. Im gonna try the 2.5.2 version

[JerryChen97]

I haven't managed to build MAGMA with CMake. My CMake all the time reports some irrelevant error about pthread. I will try make again.

[martin-frbg]

Not sure about what a make build will do - Makefile.gen has it as liblapackest_old (and I am travelling with a laptop that does not support CUDA so probably will not get Magma to build)

[brada4]

MAGMA links to OpenMP, probably OpenBLAS needs matching USE_OPENMP=1 for best performance. It will not change export symbols or otherwise assist with usability in MAGMA.

As a stopgap measure you can try patching out test functions from header and test script, and disable respective math (LINPACK included with LAPACK) tests from reaching target library where they will stay unused....