[WIP,Testing] check 32bit manylinux build

[martin-frbg]

No description provided.

[mattip]

The image is i686 (missing the i). I would suggest using manylinux2014 rather than manylinux1

Suggested change

	echo "FROM quay.io/pypa/manylinux1_686
	echo "FROM quay.io/pypa/manylinux2014_i686

[mattip]

Building the library is failing with ar: strmm_kernel_LN.o: No such file or directory. In the raw logs at the compilation of strmm_kernel_LN.o, I see that the C file is missing from the end of the cc command, note the empty directory and the compiler warning. This happens for all the strmm kernels, but only those.

cc -O2 -DMAX_STACK_ALLOC=2048 \
    -DEXPRECISION -m128bit-long-double -Wall -m32 -DF_INTERFACE_GFORT -fPIC -DNO_AVX \
    -DNO_AVX512 -DSMP_SERVER -DNO_WARMUP -DMAX_CPU_NUMBER=2 -DMAX_PARALLEL_NUMBER=1 \
    -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 \
    -DVERSION=\"0.3.29.dev\" -msse -msse2 -msse3 -mssse3 -msse4.1 -UASMNAME -UASMFNAME \
    -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -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
cc: warning: ../kernel/x86/: \
    linker input file unused because linking not done

[martin-frbg]

In my local build it is using the 4x4 gemm kernel for penryn (as it should) - I have no idea what causes the weird truncation of the source path here (which, I note, is a different error from your build problem too)

[mattip]

Sorry for the noise, I probably do not understand how this is supposed to work. TL;DR: could you add a debug line to print the Dockerfile?

If I try to reproduce exactly this script and do

$echo "FROM quay.io/pypa/manylinux1_x86_64
        COPY . /tmp/openblas
        RUN cd /tmp/openblas                                      &&  \
            COMMON_FLAGS='DYNAMIC_ARCH=1 TARGET=NEHALEM NUM_THREADS=32' && \
            BTYPE='BINARY=64' CC=gcc && \
            make QUIET_MAKE=1 $COMMON_FLAGS $BTYPE && \
            make -C test $COMMON_FLAGS $BTYPE && \
            make -C ctest $COMMON_FLAGS $BTYPE && \
            make -C utest $COMMON_FLAGS $BTYPE" > Dockerfile

and then examine the Dockerfile, it does not look like the environment variables $COMMON__FLAGS and $BTYPE appear:

$cat Dockerfile
FROM quay.io/pypa/manylinux1_x86_64
        COPY . /tmp/openblas
        RUN cd /tmp/openblas                                      &&              COMMON_FLAGS='DYNAMIC_ARCH=1 TARGET=NEHALEM NUM_THREADS=32' &&             BTYPE='BINARY=64' CC=gcc &&             make QUIET_MAKE=1   &&             make -C test   &&             make -C ctest   &&             make -C utest

[mattip]

Ahh, nevermind, you eliminated the use of the env variables.

[mattip]

The CI run has a checkmark, but the tests did not run. The last line of the logs is

InvalidBaseImagePlatform: Base image quay.io/pypa/manylinux2014_i686 was pulled with platform "linux/386", expected "linux/amd64" for current build (line 1)

I wonder if it would work to use docker run instead of docker build.

[martin-frbg]

The CI run has a checkmark, but the tests did not run. The last line of the logs is

InvalidBaseImagePlatform: Base image quay.io/pypa/manylinux2014_i686 was pulled with platform "linux/386", expected "linux/amd64" for current build (line 1)

I wonder if it would work to use docker run instead of docker build.

It's a warning not an error - possibly caused by the underlying Ubuntu platform being 64bit. The tests did generate output and appear to pass if I compile everything at "-g" - I'm currently trying to find which file needs to be compiled without optimization when gcc is "so old"

[martin-frbg]

seems it was actually the x86 CDOT that was throwing NANs (with the old manylinux gcc/libm) that the original CSCAL then purged. closing here as superseded by #5312