building with mingw 8.1.0, static library is missing dgetri?

[mattip]

In the MacPython/openblas-libs repo we build with mingw v8.1.0 on windows. There seems to be a problem with the test.f90 compilation, it cannot link, with the error that dgetri is not exported from the library. Indeed, if I do objdump -x |grep dgetr (in gitbash) I do not see it, but I do see traces of it:

$ objdump -x /c/opt/64/lib/libopenblas_v0.3.11-gcc_8_1_0.dll.a |grep dgetr
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 dgetrs_
[  6](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_dgetrs_
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 dgetrs
[  6](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_dgetrs
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 dgetrf_
[  6](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_dgetrf_
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 dgetrf
[  6](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_dgetrf
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 LAPACKE_dgetrs_work
[  6](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_LAPACKE_dgetrs_work
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 LAPACKE_dgetrs
[  6](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_LAPACKE_dgetrs
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 LAPACKE_dgetri_work
[  6](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_LAPACKE_dgetri_work
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 LAPACKE_dgetri
[  6](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_LAPACKE_dgetri
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 LAPACKE_dgetrf_work
[  6](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_LAPACKE_dgetrf_work
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 LAPACKE_dgetrf2_work
[  6](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_LAPACKE_dgetrf2_work
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 LAPACKE_dgetrf2
[  6](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_LAPACKE_dgetrf2
[  5](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 LAPACKE_dgetrf
[  6](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __imp_LAPACKE_dgetrf

This code used to work, I wonder what changed.

[mattip]

I see the travis run on linux also errors, with missing symbols when linking. Maybe there is a problem with the commands we use on windows and linux. Should we update them somehow?

[mattip]

xref MacPython/openblas-libs#43

[martin-frbg]

I think isuruf just fixed that for me in #2919, seems I had left some copypaste mistakes in the lapack makefiles when i split the object lists according to data type.

[mattip]

Thanks. #2919 fixes the windows builds (including the 64-bit interface one), but the linux ones built using the 64-bit interface still are broken. These add INTERFACE64=1 SYMBOLSUFFIX=64_ to the make arguments, perhaps some of our scripts need updating?

[mattip]

it seems like a problem in make test in exports/Makefile with the linktest.c compilation

[isuruf]

Please try latest commit on develop. #2909 should fix that.

[martin-frbg]

There may be an additional problem with the gensymbol script - I fear my former self switched to calling the lapackobjs2... variables
lapack2objs... at some point (or something like that, I am just getting ready to debug this - nightmare fuel)

[isuruf]

Are we sure #2909 doesn't fix it? I had the same problem which was fixed by #2909.

[martin-frbg]

Unfortunately yes - I had already begun building a new Windows binary with your fixes last night and that was definitely still missing symbols compared to 0.3.10. (Actually I think now my misgivings were correct - and your #2919 probably does not clear up the "lapack2" naming confusion completely - also the lapack_deprecated_objs get dropped after the initial enumeration. Testing a fix but do not want to rush it again)

[mattip]

I didn't mean to pressure you. It is fine if it takes a few days to get right. This was a big release.

[isuruf]

Yes, you are right. There are missing symbols comparing develop against 0.3.10. Here's a list https://gist.github.com/isuruf/9974570e586c959447c0aca893ef4ddd