Bug#677165: openblas: FTBFS[kfreebsd]: gemm.c:401:16: error: 'GEMM_MULTITHREAD_THRESHOLD' undeclared (first use in this function)

[Sébastien Villemot]

Christoph Egger <christoph at debian.org> writes:

> Package: src:openblas
> Version: 0.1.1-3
> Severity: serious
> Tags: sid wheezy
> User: debian-bsd at lists.debian.org
> Usertags: kfreebsd
> X-Debbugs-Cc: debian-bsd at lists.debian.org
> Justification: fails to build from source (but built successfully in the past)

> Your package failed to build on the kfreebsd-* buildds:
>
> gcc -c -O2 -DEXPRECISION -m128bit-long-double -Wall -m64 -DF_INTERFACE_GFORT -fPIC  -DDYNAMIC_ARCH -DNO_LAPACK -DNO_LAPACKE -DSMP_SERVER -DMAX_CPU_NUMBER=2 -DASMNAME=sgemm -DASMFNAME=sgemm_ -DNAME=sgemm_ -DCNAME=sgemm -DCHAR_NAME=\"sgemm_\" -DCHAR_CNAME=\"sgemm\" -DNO_AFFINITY -I.. -I. -UDOUBLE  -UCOMPLEX gemm.c -o sgemm.o
> gemm.c: In function 'sgemm_':
> gemm.c:401:16: error: 'GEMM_MULTITHREAD_THRESHOLD' undeclared (first use in this function)
> gemm.c:401:16: note: each undeclared identifier is reported only once for each function it appears in
> make[2]: *** [sgemm.o] Error 1
>
> Full build log at
> https://buildd.debian.org/status/logs.php?pkg=openblas&ver=0.1.1-3&arch=kfreebsd-amd64

The build fails because the CPU is not correctly detected on some
kfreebsd buildds (finzi, fano). From the old logs, it looks that the CPU
is correctly detected on some others kfreebsd buildds (field, fasch).

The failure to detect the CPU is a bug in itself, but we need to know
the exact CPU architecture of these buildds in order to report an
upstream bug. Is this information available?

Anyways, I think that the build of the generic openblas package should
not depend on the CPU detection of the buildd. The solution seems to
force the "generic" target (only possible when building the dynamic arch
binaries). I attach a patch to debian/rules. A second patch is attached
which fixes an error in the "generic" profile; it should probably be
forwarded upstream.

I tried to test these patches on a kfreebsd-i386 virtual machine, but
the CPU was correctly detected there and the build was not failing. As
an alternative, I tested the patches on a source tree for which I had
manually broken the CPU detection (so that getarch_2nd does not compile
as on the faulty buildds), and the compilation succeeded with the patch.

Hope this helps,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rules_target_generic.patch
Type: text/x-diff
Size: 711 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20120612/e4495bde/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: generic_profile.patch
Type: text/x-diff
Size: 1416 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20120612/e4495bde/attachment-0001.patch>
-------------- next part --------------


-- 
S?bastien Villemot
Researcher in Economics & Debian Maintainer
http://www.dynare.org/sebastien
Phone: +33-1-40-77-84-04 - GPG Key: 4096R/381A7594
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20120612/e4495bde/attachment.pgp>