Summary: | dev-python/rpy-2.0.2 setup.py fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Helmut Jarausch <jarausch> |
Component: | [OLD] Development | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED LATER | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Helmut Jarausch
2009-03-23 16:44:37 UTC
Hello, I cannot reproduce this on on x86 with python-2.5.4.. Can somebody check this out on amd64 please? Best regards, This is probably due to the fact you are using acml as a blas/lapack implementation. Could you show the output for "eselect lapack list"? Note if you are using acml-4.1.0 with gfortran, you need gcc-4.2.4, which you don't seem to have selected given your emerge --info. No matter what, I would recommand using another lapack implementation, re-emerging R and rpy. (In reply to comment #2) > This is probably due to the fact you are using acml as a blas/lapack > implementation. > > Could you show the output for "eselect lapack list"? > > Note if you are using acml-4.1.0 with gfortran, you need gcc-4.2.4, which you > don't seem to have selected given your emerge --info. > No matter what, I would recommand using another lapack implementation, > re-emerging R and rpy. > eselect lapack list shows acml-gfortran-openmp, indeed. But after eselect lapack <atlas>, reemering R and rpy it still fails - see below. setup.py executes: /usr/lib64/R/bin/R CMD config LAPACK_LIBS which still shows -Wl,--no-as-needed -L/usr/lib64/lapack/atlas -L/opt/acml4.2.0/gfortran64_mp/lib -llapack -latlas -lacml_mp -lacml_mv -lgfortran -lpthread -lcblas Failed to emerge dev-python/rpy-2.0.2, Log file: >>> '/var/tmp/portage/dev-python/rpy-2.0.2/temp/build.log' >>> Jobs: 1 of 2 complete, 1 failed Load avg: 1.37, 1.26, 0.58 >>> Unpacking source... >>> Unpacking rpy2-2.0.2.tar.gz to /var/tmp/portage/dev-python/rpy-2.0.2/work >>> Source unpacked in /var/tmp/portage/dev-python/rpy-2.0.2/work >>> Preparing source in /var/tmp/portage/dev-python/rpy-2.0.2/work/rpy2-2.0.2 ... * Applying rpy-2.0.1-setup.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/dev-python/rpy-2.0.2/work/rpy2-2.0.2 ... >>> Source configured. >>> Compiling source in /var/tmp/portage/dev-python/rpy-2.0.2/work/rpy2-2.0.2 ... Traceback (most recent call last): File "setup.py", line 144, in <module> ri_ext = getRinterface_ext(RHOME, r_packversion) File "setup.py", line 129, in getRinterface_ext tuple(get_rconfig(RHOME, 'LAPACK_LIBS')[0].split()) +\ File "setup.py", line 78, in get_rconfig raise Exception(cmd + '\nreturned\n' + rconfig) Exception: "/usr/lib64/R/bin/R" CMD config LAPACK_LIBS returned -Wl,--no-as-needed -L/usr/lib64/lapack/atlas -L/opt/acml4.2.0/gfortran64_mp/lib -llapack -latlas -lacml_mp -lacml_mv -lgfortran -lpthread -lcblas * * ERROR: dev-python/rpy-2.0.2 failed. You need also to reselect blas (and cblas if you don't want to ask for trouble). If you go for atlas, make sure you eselect blas/cblas to atlas(-threads) and lapack to atlas. You also want to make sure you did install lapack-atlas with atlas(-threads) selected as blas and cblas. Check the result of "pkg-config --libs blas cblas lapack" which should be free of any acml stuff. Then re-emerge R and rpy. I know this is a bit messy, hopefully I will find the time to regularize all the lapack libs. Thanks (In reply to comment #4) > You need also to reselect blas (and cblas if you don't want to ask for > trouble). > If you go for atlas, make sure you eselect blas/cblas to atlas(-threads) and > lapack to atlas. You also want to make sure you did install lapack-atlas with > atlas(-threads) selected as blas and cblas. > Check the result of "pkg-config --libs blas cblas lapack" which should be free > of any acml stuff. > Then re-emerge R and rpy. > > I know this is a bit messy, hopefully I will find the time to regularize all > the lapack libs. > Thanks Thanks, now it installed without problems. But atlas provides less performance than libgoto or libacml which provides more functions. What's the problem with libacml and gfortran-4.3.3 ? Thanks, Helmut. (In reply to comment #5) > Thanks, now it installed without problems. > But atlas provides less performance than libgoto or libacml which provides > more functions. You can also eselect blas goto, cblas reference, and lapack reference. I doubt that for rpy you will see a difference in speed though. > What's the problem with libacml and gfortran-4.3.3 ? AMD devs compiled acml-4.1 with gfortran 4.2. And before 4.3, the libgfortran abi were not compatible among versions. Closing this bug to be resolved when acml package and ebuilds are more stable. |