On Tue, 2008-09-02 at 12:52 -0500, Dirk Eddelbuettel wrote:
> On 2 September 2008 at 18:26, Robert Nuske wrote:
> | > I may have seen that one problem mentioned earlier to the list.
> | me to, but can't find it now
> |
> | > The location of R's include files is seemingly a bit too exotic for the
> | > disutils script.
> | they were placed there by the debian package
>
> Yes, as we were once asked / forced to place architecture-independent files
> below /usr/share/
>
> | > The setup.py script expects them to be in ${RHOME}/include
> | > (RHOME being the outcome of running 'R RHOME').
> |
> | by googeling R_INCLUDE_DIR I found that it is not recommended to rely on
> | ${RHOME}/include
> |
> | eg.
> |
> http://www.nabble.com/Bug-354775%3A-r-base-core%3A-R-CMD-config-doesn%27t-reflect-new-file-locations-tp3175446p3175720.html
>
> It works always everywhere but alas not on Debian.
> | > There is currently no other way around that than either
> | > - edit setup.py
> | > - copy or link the headers.
> |
> | one way to get the include dirs
> | R CMD echo $R_INCLUDE_DIR
>
> For rpy (v1) it works out-of-the-box on all Debian systems. But as I recall
> that may have taken Greg and myself a few iterations over setup.py.
>
> I'm sure we can achieve the same for rpy v2, I just haven't gotten to it yet.
I looked at the one for rpy in the begining, dismantled it, then built
it again. There were nuts and bolts left on the side when I was done...
may be they were not useless... ;-)
I have it working with --cppflags on ubuntu (and that's debian-based,
isn't it ?)
(more below)
> | but the recommed way of finding the include dirs seems to be:
> | R CMD config --cppflags
> |
> | on my system this returns
> | -I/usr/share/R/include -I/usr/share/R/include
> |
> | but I can't use it with get_rconfig, since get_rconfig checks for -l/-L and
> | raises an ecxecption otherwise, more or less
> |
> |
> | If I hardcode the include dir in setup.py it finds the headers, but stops
> | with:
> |
> | [EMAIL PROTECTED]:/usr/local/src/rpy_nextgen$ python setup.py install
> | running install
> | running build
> | running build_py
> | running build_ext
> | building 'rpy2.rinterface.rinterface' extension
> | gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
> | build/temp.linux-i686-2.5/rpy/rinterface/array.o
> | build/temp.linux-i686-2.5/rpy/rinterface/r_utils.o
> | build/temp.linux-i686-2.5/rpy/rinterface/rinterface.o -L/usr/lib/R/lib
> -L/usr/lib/R/modules -Wl,-R/usr/lib/R/lib -Wl,-R/usr/lib/R/modules -lR
> -lRlapack -lRblas -o
> | build/lib.linux-i686-2.5/rpy2/rinterface/rinterface.so -L/usr/lib/R/lib -lR
> -llapack -lblas
> | /usr/bin/ld: cannot find -lRlapack
> | collect2: ld returned 1 exit status
> | error: command 'gcc' failed with exit status 1
>
> Similarly, prior to the new gfortran-built liblapack / libblas / libatlas
> packages, we used to build R with its copy of Lapack --- hence -lRlapack.
>
> Since last winter, however, we have newer / better lapack libs and no longer
> use R's lapack source --- hence now
>
> [EMAIL PROTECTED]:~> R CMD config --ldflags
> -L/usr/lib/R/lib -lR
> [EMAIL PROTECTED]:~> R CMD config LAPACK_LIBS
> -llapack
> [EMAIL PROTECTED]:~>
rpy2's setup.py is getting its LAPACK (and BLAS) info
from R CMD config (but now I see that it is also using Rblas and Rlapack
no matter what).
Easy to fix (and fixed soon).
> Hth, Dirk
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
