Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

currently the R ebuild uses the 64-bit eclass to detect whether the system is
64bit ... the eclass is an ugly hack and the ebuild should move to using a
compile-time detection routine

Hey Mike,
the problem is as follows: dev-lang/R works wonderfully on 64bit system as long as
you use a native FORTRAN compiler (tested with both ifc and g77, g95/gfortran test
is still pending). Now the BIG BUT: Compiling it with f2c produces badass code.
As we use fortran.eclass to specify all the FORTRAN compiler that can be used with a package, we need to make sure to _not specify_ f2c on 64bit machines. In fact,
newer versions (>2.0.0 afaik) of R detect f2c on 64bit during configure already,
but it would be kind to tell the user early about this.

I don't see an easy way to accomplish this out of hand, but i'm always open to proposals. /me too would like to get rid of 64-bit.eclass ;-)

I was just trying to figure out the best way to modify the ebuild after reading
through all the old bug reports. I assumed testing for ${ARCH} in the ebuild
would be just as bad too.

i understand the issue, i just want 64-bit.eclass gone ;)

i dont know anything about the build system of R, but here's a safe test for multilib/cross-compiling/etc... that you could use in the ebuild:

echo 'int main(){}' > test.c
$(tc-getCC) -c test.c -o test.o
if file test.o | grep -qs 64-bit ; then
    64 bit !
else
    32 bit !
fi

Thanks SpanKY - I have added this detection code to 2.1.0-r1. I would like
testing on this version, and I will backport the new detection code to the
stable 2.0.1 and 1.9.0-r1 ebuilds.

Right, I have committed the new 64 bit detection code to 2.1.0-r1 and 2.0.1
now.
Everyone has stabilised on 2.0.1 and to the old 1.9.0-r1 is gone and R no
longer
uses the 64-bit eclass. Hope that's OK. Let me know if there are any problems
at
all.

Reopened pending removal of dev-python/rpy-0.3.5 

Removed now thanks to kloeri removing dev-python/rpy-0.3.5 - thanks. 

This test create/overwrite test.c and test.o in the current directory where
emerge is started. This is BAD! Could you use a safer directory?

that's already been fixed in unstable versions