undefined reference error with MinGW on W10

[RemiDav]

I get the following error when trying to compile using MinGW:

/mingw32/bin/ld.exe: ../lib/libopenblas.a(scopy.c.obj):scopy.c:(.text+0x87): undefined reference to 'scopy_k'
/mingw32/bin/ld.exe: ../lib/libopenblas.a(dcopy.c.obj):dcopy.c:(.text+0x87): undefined reference to 'dcopy_k'
/mingw32/bin/ld.exe: ../lib/libopenblas.a(ccopy.c.obj):ccopy.c:(.text+0x87): undefined reference to 'ccopy_k'
/mingw32/bin/ld.exe: ../lib/libopenblas.a(zcopy.c.obj):zcopy.c:(.text+0x87): undefined reference to 'zcopy_k'
/mingw32/bin/ld.exe: ../lib/libopenblas.a(srot.c.obj):srot.c:(.text+0xa9): undefined reference to 'srot_k'
/mingw32/bin/ld.exe: ../lib/libopenblas.a(drot.c.obj):drot.c:(.text+0xa9): undefined reference to 'drot_k'

It seems similar to #1701 .
However, it seems this issue hasn't been resolved, or if so, I do not understand how.

I tried both v3.6.0 and the current devel.

Compiled using:

cmake .. -G "MSYS Makefiles"
make

nm finds that the symbol is there but undefined. Do I need to link against another library that is not automatically linked by make ?

[martin-frbg]

This issue has not been resolved, and I have no idea yet what could be causing it. (Unless something went wrong while building these cpu-specific files - do you see any warnings for the "kernel.dir" parts of the build during the make phase ? (You will probably need to run cmake with -DCMAKE_VERBOSE_MAKEFILE=1 to see them)
And do you have a file srot_k.S (or srot_k.c, depending on your cpu) in kernel\CMakeFiles ? This should look something like

#define ASMNAME srot_k
#define ASMFNAME srot_k_
#define NAME srot_k_
#define CNAME srot_k
#define CHAR_NAME "srot_k_"
#define CHAR_CNAME "srot_k"
#include ..."

(with the source file name on the include line again depending on your target cpu)

[RemiDav]

I do have srot_k.S looking as described.
I will try to catch if I see any warning, so far I didn't see anything weird looking at the log.

Note that I just successfully compiled it by not using cmake and directly using MSYS make instead in the main dir:

make CC=gcc FC=gfortran BINARY=64 USE_THREADS=1 NUM_THREADS=64 TARGET=SANDYBRIDGE

The output linked well in my other project without any undefined reference error.

[brada4]

Could you attach /not paste text/ cmake log (as detailed as possible) ?
It looks like some big part of openblas did not get built. There is no error if cmake does not emit makefile.

[RemiDav]

Where is the log or how do I generate it ? (Sorry I'm a beginner) Are you talking about the command line output ? Or is there a way to get a log with more details ?

…

On Sun, 16 Jun 2019 at 04:29, Andrew ***@***.***> wrote: Could you attach /not paste text/ cmake log (as detailed as possible) ? It looks like some big part of openblas did not get built. There is no error if cmake does not emit makefile. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2163>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANMUW5U4WG5BCGOEOBXKCLP2X2XVANCNFSM4HYPPZUQ> .

[martin-frbg]

Just the command line output - you will probably need to redirect it to a file by adding something like > makelog 2>&1 to the end of your make line. (The 2>&1 is to redirect error messages from stderr to the same file, I am not entirely sure if this works in the msys shell Windows)

[brada4]

The problem is that cmake did not emit Makefile or its parts to build those _k files, or those come out of order later than other files depending on the,
Probably, starting on an empty build directory, under openblas source tree
cmake --trace .. 2>&1 | tee cmake_log.txt

[martin-frbg]

Does it work when you tell cmake to generate "MinGW Makefiles" rather than MSYS ? I tried adding a cmake/mingw build to our Appveyor CI setup and the build appeared to work fine with those

[brada4]

I did not mention but I intentionally did not specify generator so that cmake picks first working one.

[martin-frbg]

"MSYS Makefiles" build just passed on Appveyor as well, so it does not appear to be a general problem.
(autodetected TARGET was HASWELL however, and from the "mingw32" in the first message here the problem may be with 32bit builds (?)

[RemiDav]

"MinGW Makefiles" didn't work either. I tried this before trying the MSYS option actually.

makelog.txt

[brada4]

Could you , please, post the log of cmake invocation? Damage is done there.

[martin-frbg]

msys/cmake build with TARGET=SANDYBRIDGE BINARY=32 passed on Appveyor as well, suggesting nothing wrong with our cmake configuration files. Do you happen to have several versions of mingw installed on your W10 system, or something like that which might lead to mixups ?

[RemiDav]

This is the result of
'''
\build> cmake .. -G "MSYS Makefiles" > cmakelog 2>&1
'''
cmakelog.txt

I only have one version on MinGW, that I used to compile most of my other libraries without issues so far.
I am trying to think what could cause a mixup, but nothing comes to mind so far.

[brada4]

Now examine likewise captured output of make for scopy_k being compiled (or not)
Also try cmake without specifying generator, so that cmake uses its internal logic to determine generator type. It might be some small thing is missing so that it goes and detects makefile generators as not viable.
OpenBLAS also compiles without issues unless you get into experimental cmake world... Though we intend to keep it working well for everybody.

[martin-frbg]

What I find interesting in the cmakelog is that it reads part of the configuration from KERNEL.PENRYN, in what must be an automatic fallback to 32bit mode due to a 32bit compiler environment. When -DBINARY=32 is specified as a cmake argument, dedicated code in system.cmake switches the target to NEHALEM and the compilation works in my Appveyor tests.
So there could be a problem with our fallback logic, although in the end the x86 KERNEL.HASWELL and KERNEL.NEHALEM configurations are absolutely identical (each just forwarding to KERNEL.PENRYN) - the difference must be either the implied NO_AVX=1 or something in the cpu-specific settings from param.h
On the other hand, your successful make based compilation had BINARY=64 and a SANDYBRIDGE cpu - did that actually use the same compiler (or was it on a completely different computer), and do you want to build for 32 or 64 bit ?