Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 91512
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Gentoo Science Related Packages <sci@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: SpanKY <vapier@gentoo.org>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 91512 depends on: 95881 Show dependency tree
Bug 91512 blocks: 55238
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2005-05-04 19:57 0000
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

------- Comment #1 From Danny van Dyk (RETIRED) 2005-05-06 15:31:15 0000 -------
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 ;-)

------- Comment #2 From Marcus D. Hanwell 2005-05-06 16:24:29 0000 -------
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.

------- Comment #3 From SpanKY 2005-05-06 16:34:14 0000 -------
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

------- Comment #4 From Marcus D. Hanwell 2005-05-07 18:16:56 0000 -------
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.

------- Comment #5 From Marcus D. Hanwell 2005-05-25 06:38:30 0000 -------
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.

------- Comment #6 From Marcus D. Hanwell 2005-06-12 11:04:33 0000 -------
Reopened pending removal of dev-python/rpy-0.3.5 

------- Comment #7 From Marcus D. Hanwell 2005-06-12 11:25:13 0000 -------
Removed now thanks to kloeri removing dev-python/rpy-0.3.5 - thanks. 

------- Comment #8 From Jules Gagnon 2006-04-10 11:45:19 0000 -------
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?

------- Comment #9 From SpanKY 2006-04-10 15:23:49 0000 -------
that's already been fixed in unstable versions

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug