On 12 May 2010 at 00:39, Modestas Vainius wrote:
| Source: r-base
| Version: 2.11.0-1
| Severity: normal
|
| Hello,
|
| I stumbled upon this issue while analizing kdeedu FTBFS [1] on armel. It is
| caused by likely buggy kdeedu buildsystem settings when
| /usr/lib/R/lib/libRlapack.so is present. So it is not the fault of the
| r-base-core package directly.
|
| But this issue left me wondering why armel is the *only* architecture which
| still builds /usr/lib/R/lib/lib{Rblas,Rlapack}.so:
|
| $ wget -O amd64_filelist
http://packages.debian.org/sid/amd64/r-base-core/filelist
| $ wget -O armel_filelist
http://packages.debian.org/sid/armel/r-base-core/filelist
| <strip irrelevant html and text from both>
| $ diff -u amd64_filelist armel_filelist
| --- amd64_filelist 2010-05-12 00:03:42.000000000 +0300
| +++ armel_filelist 2010-05-12 00:04:00.000000000 +0300
| @@ -45,6 +45,8 @@
| /usr/lib/R/etc/ldpaths
| /usr/lib/R/etc/repositories
| /usr/lib/R/lib/libR.so
| +/usr/lib/R/lib/libRblas.so
| +/usr/lib/R/lib/libRlapack.so
| /usr/lib/R/library/R.css
| /usr/lib/R/library/base/CITATION
| /usr/lib/R/library/base/DESCRIPTION
|
| Then I saw this old code in debian/rules:
|
| # edd 14 Nov 2003 turn blas off on arm
| ifeq ($(arch),arm)
| atlas = --without-blas
| endif
There will have been a problem at the time...
Looking at rmadison:
e...@ron:~$ rmadison libatlas-base-dev
libatlas-base-dev | 3.6.0-22 | stable | amd64, hppa, i386, ia64, mips,
mipsel, powerpc, s390, sparc
libatlas-base-dev | 3.6.0-24 | testing | amd64, hppa, i386, ia64,
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
libatlas-base-dev | 3.6.0-24 | unstable | mips, mipsel
libatlas-base-dev | 3.8.3-19 | unstable | sparc
libatlas-base-dev | 3.8.3-20 | unstable | alpha
libatlas-base-dev | 3.8.3-21 | unstable | amd64, armel, hppa, i386,
ia64, kfreebsd-amd64, kfreebsd-i386, powerpc, s390
e...@ron:~$
it would seem that we can indeed lift this. Could you try a built on armel
with this restriction in debian/rules?
| As far as I can tell, --without-blas disables detection of system blas at
| configure stage. But libblas-dev build dependency is NOT arch specific (or it
| should be [!armel]). What is more, there is also the following at m4/R.m4:2894
|
| # We cannot use LAPACK if BLAS is not found
| if test "x${acx_blas_ok}" != xyes; then
| acx_lapack_ok=noblas
| fi
|
| So system lapack cannot be used if system blas is not used yet --with-lapack
is
| passed to configure on armel by debian/rules. And again, liblapack-dev build
| dependency is NOT architecture specific.
|
| So my question is if that --without-blas is still intentional nowadays. I
would
| appretiate quick answer or upload because kdeedu is part of ongoing KDE SC
| 4.4.3 transition. Initial 10 days is about to expire for majority of other KDE
| SC packages.
|
| If /usr/lib/R/lib/libRlapack.so is intentional on armel, I will have to fix
| kdeedu build system and if it is not, I could wait a bit until fixed r-base is
| uploaded to sid and request a give back.
libRblas and libRlapack are related but independent. They use R-internal
source if no system source were found or specified.
We may indeed be able to overcomes this. Would you have time to test this?
Dirk
|
| 1.
https://buildd.debian.org/fetch.cgi?&pkg=kdeedu&ver=4%3A4.4.3-1&arch=armel&stamp=1273585548&file=log
|
| -- System Information:
| Debian Release: squeeze/sid
| APT prefers unstable
| APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
| Architecture: amd64 (x86_64)
|
| Kernel: Linux 2.6.33-2-amd64 (SMP w/1 CPU core)
| Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8)
| Shell: /bin/sh linked to /bin/dash
|
|
--
Regards, Dirk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
