Bug#923607: openblas: FTBFS if CPU is not detected

[Santiago Vila]

Package: src:openblas
Version: 0.3.5+ds-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:

--------------------------------------------------------------------------------
[...]
debian/rules binary-arch
dh binary-arch
dh_update_autotools_config -a
dh_autoreconf -a
dh_auto_configure -a
debian/rules override_dh_auto_build
make[1]: Entering directory '/<<BUILDDIR>>/openblas-0.3.3+ds'
/usr/bin/make NO_LAPACKE=1 NO_AFFINITY=1 USE_OPENMP=0 NO_WARMUP=1 CFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<<BUILDDIR>>/openblas-0.3.3+ds=. -fstack-protector-strong -Wformat -Werror=format-security" FFLAGS="-g -O2 -fdebug-prefix-map=/<<BUILDDIR>>/openblas-0.3.3+ds=. -fstack-protector-strong" COMMON_OPT= FCOMMON_OPT=-frecursive NUM_THREADS=64 DYNAMIC_ARCH=1 DYNAMIC_OLDER=1
make[2]: Entering directory '/<<BUILDDIR>>/openblas-0.3.3+ds'
getarch_2nd.c: In function 'main':
getarch_2nd.c:12:35: error: 'SGEMM_DEFAULT_UNROLL_M' undeclared (first use in this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
printf("SGEMM_UNROLL_M=%d\n", SGEMM_DEFAULT_UNROLL_M);
^~~~~~~~~~~~~~~~~~~~~~
XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:12:35: note: each undeclared identifier is reported only once for each function it appears in
getarch_2nd.c:13:35: error: 'SGEMM_DEFAULT_UNROLL_N' undeclared (first use in this function); did you mean 'XGEMM_DEFAULT_UNROLL_N'?
printf("SGEMM_UNROLL_N=%d\n", SGEMM_DEFAULT_UNROLL_N);
^~~~~~~~~~~~~~~~~~~~~~
XGEMM_DEFAULT_UNROLL_N
getarch_2nd.c:14:35: error: 'DGEMM_DEFAULT_UNROLL_M' undeclared (first use in this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
printf("DGEMM_UNROLL_M=%d\n", DGEMM_DEFAULT_UNROLL_M);
^~~~~~~~~~~~~~~~~~~~~~
XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:15:35: error: 'DGEMM_DEFAULT_UNROLL_N' undeclared (first use in this function); did you mean 'XGEMM_DEFAULT_UNROLL_N'?
printf("DGEMM_UNROLL_N=%d\n", DGEMM_DEFAULT_UNROLL_N);
^~~~~~~~~~~~~~~~~~~~~~
XGEMM_DEFAULT_UNROLL_N
getarch_2nd.c:19:35: error: 'CGEMM_DEFAULT_UNROLL_M' undeclared (first use in this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
printf("CGEMM_UNROLL_M=%d\n", CGEMM_DEFAULT_UNROLL_M);
^~~~~~~~~~~~~~~~~~~~~~
XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:20:35: error: 'CGEMM_DEFAULT_UNROLL_N' undeclared (first use in this function); did you mean 'XGEMM_DEFAULT_UNROLL_N'?
printf("CGEMM_UNROLL_N=%d\n", CGEMM_DEFAULT_UNROLL_N);
^~~~~~~~~~~~~~~~~~~~~~
XGEMM_DEFAULT_UNROLL_N
getarch_2nd.c:21:35: error: 'ZGEMM_DEFAULT_UNROLL_M' undeclared (first use in this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
printf("ZGEMM_UNROLL_M=%d\n", ZGEMM_DEFAULT_UNROLL_M);
^~~~~~~~~~~~~~~~~~~~~~
XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:22:35: error: 'ZGEMM_DEFAULT_UNROLL_N' undeclared (first use in this function); did you mean 'XGEMM_DEFAULT_UNROLL_N'?
printf("ZGEMM_UNROLL_N=%d\n", ZGEMM_DEFAULT_UNROLL_N);
^~~~~~~~~~~~~~~~~~~~~~
XGEMM_DEFAULT_UNROLL_N
getarch_2nd.c:69:50: error: 'SGEMM_DEFAULT_Q' undeclared (first use in this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
printf("#define SLOCAL_BUFFER_SIZE\t%ld\n", (SGEMM_DEFAULT_Q * SGEMM_DEFAULT_UNROLL_N * 4 * 1 * sizeof(float)));
^~~~~~~~~~~~~~~
XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:70:50: error: 'DGEMM_DEFAULT_Q' undeclared (first use in this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
printf("#define DLOCAL_BUFFER_SIZE\t%ld\n", (DGEMM_DEFAULT_Q * DGEMM_DEFAULT_UNROLL_N * 2 * 1 * sizeof(double)));
^~~~~~~~~~~~~~~
XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:71:50: error: 'CGEMM_DEFAULT_Q' undeclared (first use in this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
printf("#define CLOCAL_BUFFER_SIZE\t%ld\n", (CGEMM_DEFAULT_Q * CGEMM_DEFAULT_UNROLL_N * 4 * 2 * sizeof(float)));
^~~~~~~~~~~~~~~
XGEMM_DEFAULT_UNROLL_M
getarch_2nd.c:72:50: error: 'ZGEMM_DEFAULT_Q' undeclared (first use in this function); did you mean 'XGEMM_DEFAULT_UNROLL_M'?
printf("#define ZLOCAL_BUFFER_SIZE\t%ld\n", (ZGEMM_DEFAULT_Q * ZGEMM_DEFAULT_UNROLL_N * 2 * 2 * sizeof(double)));
^~~~~~~~~~~~~~~
XGEMM_DEFAULT_UNROLL_M
make[2]: *** [Makefile.prebuild:66: getarch_2nd] Error 1
Makefile:135: *** OpenBLAS: Detecting CPU failed. Please set TARGET explicitly, e.g. make TARGET=your_cpu_target. Please read README for the detail.. Stop.
make[2]: Leaving directory '/<<BUILDDIR>>/openblas-0.3.3+ds'
make[1]: *** [debian/rules:77: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<<BUILDDIR>>/openblas-0.3.3+ds'
make: *** [debian/rules:74: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2
--------------------------------------------------------------------------------

The error message says it all: Please set TARGET explicitly.

The fact that this package tries to detect the CPU is probably the
reason the executables built in buildd.debian.org do not work
everywhere:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743490
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781998

which in addition to the FTBFS bug, it's also a baseline violation.

(Not to mention that detecting the CPU at build time makes the package
not to be reproducible).

[ Note: Based on the above, I believe it is clear that the only
sensible course of action is to set the target explicitly, but if
you still require a test machine where this happens, please contact
me privately and I will gladly offer ssh access ]

Thanks.

[Sébastien Villemot]

Dear Santiago,

Post by Santiago Vila
Package: src:openblas
Version: 0.3.5+ds-2
Severity: serious
Tags: ftbfs

[
]

Post by Santiago Vila
make[2]: *** [Makefile.prebuild:66: getarch_2nd] Error 1
Makefile:135: *** OpenBLAS: Detecting CPU failed. Please set TARGET explicitly, e.g. make TARGET=your_cpu_target. Please read README for the detail..  Stop.
make[2]: Leaving directory '/<<BUILDDIR>>/openblas-0.3.3+ds'
make[1]: *** [debian/rules:77: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<<BUILDDIR>>/openblas-0.3.3+ds'
make: *** [debian/rules:74: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2
--------------------------------------------------------------------------------
The error message says it all: Please set TARGET explicitly.
The fact that this package tries to detect the CPU is probably the
reason the executables built in buildd.debian.org do not work
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743490
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781998
which in addition to the FTBFS bug, it's also a baseline violation.

As mentioned in the package description, on amd64, arm64 and i386, the
binary contains specialized kernels for many different micro-
architectures, and the selection of the kernel is done at runtime. So
the design is correct and there is no baseline violation.

Still there seems to be an issue with your specific build environment,
and of course this is a bug (but maybe not an RC one, since you are the
first to report such a build failure after many years). Could you give
more details about the hardware you are using?

Thanks,

[Sébastien Villemot]

Control: forwarded -1 https://github.com/xianyi/OpenBLAS/issues/2048
Control: tags -1 + upstream
Control: severity -1 important

Post by Sébastien Villemot
Still there seems to be an issue with your specific build environment,
and of course this is a bug (but maybe not an RC one, since you are the
first to report such a build failure after many years). Could you give
more details about the hardware you are using?

I'm currently using Scaleway 1-XS and 1-S instances. On both types of
instances the package always fail to build. I didn't find a way to
move the "unbuildability property" to a non-failing machine (for
example, by taking /proc/cpuinfo in the failing machine and using
bind-mount on the non-failing machine), so I decided to report it anyway
without a "recipe to reproduce it" but with an offer to ssh into a failing
machine instead.

I've tried to fix the issue by myself on the host you provided me
access to, but without success so far. Hence I have forwarded it
upstream.

I am also downgrading the severity, since the FTBFS is specific to a
seemingly small subset of machines (and in particular it never occurred
on buildds).

Best,