STRMMKERNEL not defined on x86 Haswell

[dev-zero]

when trying to build a 32bit version of OpenBLAS on a Haswell arch, I get the following error in the linking phase:

x86_64-pc-linux-gnu-ar: strmm_kernel_LN.o: No such file or directory
../Makefile.tail:40: recipe for target 'libs' failed

with the following output when strmm_kernel_LN.o should have been built:

x86_64-pc-linux-gnu-gcc -m32 -m32 -O2 -pipe -march=native -ggdb -DARCH_X86=1 -D__32BIT__=1 -DMAX_STACK_ALLOC=2048 -Wall -m32 -DF_INTERFACE_GFORT -fPIC -DNO_LAPACK -DNO_LAPACKE -DNO_AVX -DSMP_SERVER -DNO_WARMUP -DMAX_CPU_NUMBER=4 -DASMNAME=strmm_kernel_LN -DASMFNAME=strmm_kernel_LN_ -DNAME=strmm_kernel_LN_ -DCNAME=strmm_kernel_LN -DCHAR_NAME=\"strmm_kernel_LN_\" -DCHAR_CNAME=\"strmm_kernel_LN\" -DNO_AFFINITY -I.. -UDOUBLE  -UCOMPLEX -c -DTRMMKERNEL -UDOUBLE -UCOMPLEX -DLEFT -UTRANSA ../kernel/x86/ -o strmm_kernel_LN.o

which shows that $(STRMMKERNEL) us undefined.
Comparing kernel/x86_64/KERNEL.HASWELL to kernel/x86/KERNEL.PENRYN shows the missing definition of STRMMKERNEL as well.

[dev-zero]

checking the compile output, it seems that the same problem occurs for all {S,D,C,Z}TRMMKERNEL.

[xianyi]

Could you try to make clean and make BINARY=32?

We didn't optimize BLAS on Haswell 32-bit. It still uses Nehalem kernels.

[hfxunlp]

Thank you ,I'm retrying,at least seems no problems occured right now

[dev-zero]

I am currently using the following patch to make it compile:

diff --git a/kernel/x86/KERNEL.PENRYN b/kernel/x86/KERNEL.PENRYN
index f2b0f96..94b515c 100644
--- a/kernel/x86/KERNEL.PENRYN
+++ b/kernel/x86/KERNEL.PENRYN
@@ -35,6 +35,11 @@ ZGEMMITCOPYOBJ =  zgemm_itcopy$(TSUFFIX).$(SUFFIX)
 ZGEMMONCOPYOBJ =  zgemm_oncopy$(TSUFFIX).$(SUFFIX)
 ZGEMMOTCOPYOBJ =  zgemm_otcopy$(TSUFFIX).$(SUFFIX)

+STRMMKERNEL = ../generic/trmmkernel_2x2.c
+DTRMMKERNEL = ../generic/trmmkernel_2x2.c
+CTRMMKERNEL = ../generic/ztrmmkernel_2x2.c
+ZTRMMKERNEL = ../generic/ztrmmkernel_2x2.c
+
 STRSMKERNEL_LN =  trsm_kernel_LN_4x4_penryn.S
 STRSMKERNEL_LT =  trsm_kernel_LT_4x4_penryn.S
 STRSMKERNEL_RN =  trsm_kernel_LT_4x4_penryn.S

[hfxunlp]

make with arguments BINARY=32 is ok at my virtual machine, at least it can work

[LuciusV]

It fails for x86_64 as well. Any hope for fix soon?

[martin-frbg]

@LuciusV 64bit Haswell should build just fine at least on Linux (and should not require explicit specification of TARGET or BINARY). What is your compiler and operating system ? And do you get the exact same error message as documented here, or could it simply be that you are missing a compiler component ?

[LuciusV]

@martin-frbg I am using Gentoo Linux with kernel 3.8.11 and gcc version 4.9.3 and trying to compile openblas-0.2.15
My error message is the same:
"""
x86_64-pc-linux-gnu-ar: strmm_kernel_LN.o: No such file or directory
../Makefile.tail:40: recipe for target 'libs' failed
"""

[martin-frbg]

Are you trying to build a 32 or 64 bit version (i.e. do you see the same "-m32" option being passed as in the original bug report) ? And is this on "real physical hardware" or running in a vm ?

[LuciusV]

@martin-frbg Yes. there were -m32 options as in original report.
Actually patch from post
"dev-zero commented on Dec 19, 2015" would work if it will be added to distribution. I managed to compile openblas when I manually edited KERNEL.PENRYN file, adding these 4 lines and copied it into working directory during compilation, but it is still a bug there.

[martin-frbg]

So you would appear to have the exact same situation as the original poster, and just wanted to add a reminder that the changes to KERNEL.PENRYN have not been merged ? As I read xianyi's original response, running "make BINARY=32" with an otherwise unchanged distribution would appear to be the preferred solution (nehalem architecture being newer than penryn, perhaps a better fit performance-wise for actual haswell architecture as well).

[LuciusV]

@martin-frbg I (and all gentoo users) can't control make enviroment because it's run by Gentoo's portage when I 'emerge' openblas.

[martin-frbg]

I have no experience with Gentoo, but the "portage" section of the online handbook suggests one can pass options to portage via the MAKEOPTS environment variable ?

[LuciusV]

@martin-frbg yes, that will work, thanks.