[Octave-bug-tracker] [bug #63184] [MXE Octave] AMD ZEN AOCL library support for blas, lapack and fftw

[Markus Mützel]

Update of bug #63184 (project octave):

                 Release:                   7.2.0 => dev                    
        Operating System:                     Any => Microsoft Windows      
                 Summary: AMD ZEN AOCL library support for blas, lapack and
fftw => [MXE Octave] AMD ZEN AOCL library support for blas, lapack and fftw

    _______________________________________________________

Follow-up Comment #8:

Hmm. It looks like flame doesn't export that symbol.
With the binary of the reference (netlib) LAPACK bundled with Octave for
Windows:

$ objdump.exe -p /mingw64/bin/liblapack.dll | grep lsame
        [ 978] lsame_
        [ 979] lsamen_


I'm not sure if I read the lines you pasted correctly. But it looks like that
library is importing that symbol from some other library.

Looking at the reference documentation, it might be that this symbol should
indeed be exported by the BLAS library (not the LAPACK library): 
https://netlib.org/lapack/explore-html/d0/d73/group__aux__blas_gada799b40a93f1fd2c6d1a86a95f21631.html#gada799b40a93f1fd2c6d1a86a95f21631

But it might also be that the reference implementation defines the "de facto
standard".
Reading the build rules, it seems to be intentional that the reference LAPACK
implementation (also) exports `lsame`:
https://github.com/Reference-LAPACK/lapack/blob/master/SRC/Makefile#L75

FWIW, the same symbol is also exported by the reference BLAS implementation
bundled in Octave for Windows:

$ objdump.exe -p /mingw64/bin/librefblas.dll | grep lsame
        [  76] lsame_


This might be a bug in the flame implementation, or it might be an issue with
(the build rules of) the reference implementation. Or both.

Could you please check the context of the first match of "lsame" in that
objdump? Maybe with something like this:

objdump.exe -p /mingw64/bin/liblapack.dll | grep lsame -B50


>From which library does it try to import that symbol? I'd guess it might be
`AOCL-LibBlis-Win-dll.dll`.

Anyway, this is probably only an issue on Windows (where the *linker* resolves
which symbols are imported from which library). Afaict, the symbol resolution
is done on runtime on Linux.
Setting the Operating System tag accordingly.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63184>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/