Summary: | dev-lang/R-2.2.1 fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Patrizio Bassi <patrizio.bassi> |
Component: | New packages | Assignee: | Gentoo Science Related Packages <sci> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | mmokrejs |
Priority: | High | Keywords: | InVCS |
Version: | 2005.1 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Patrizio Bassi
2006-02-11 08:22:07 UTC
Have you tried it with more conservative CFLAGS? -march=pentium3 -pipe -O2 would be a good start. I am unable to reproduce the error you have seen even on my experimental system using GCC 4.1. As it is GCC 4 is still masked and some of the CFLAGS you are using are aggressive. with your suggested flags...same error. plus...is that possibile to bypass all docs? it lasts more the docs section than the real compilation after deleting my LDFLAGS too it worked. please unset LDFLAGS, this package seems too easy to break Again with less aggressive LDFLAGS it will probably be fine, but most do not play with these. I will try to find a little time to experiment this weekend. I would rather not simply unset them and need to check the ramifications for archs which might need to set things here. i suspect the problem is with -bdirect if that can help you. I don't have the time to take care of this right now and am off on holiday for a couple of weeks. We cannot simply unset LDFLAGS AFAIK. The flags you are using are fairly experimental and very few users have this type of stuff set. I would like opinions on how best to deal with this - are we going to have to start restricting LDFLAGS and various other bits now too??? We cannot protect people from every flag they might choose to apply globally to their systems... you're right, but i add this: generally those flags are safe. with generally i mean that my world is about 3700 packages and i have a really stable system. when i notice a problem with a certain package i use to fill a bug. you can't protect from all bad flag, this is true, but you can protect from known-not-working-ones. R ebuilds now have filter-ldflags -Wl,-Bdirect -Bdirect to work around this bug. InCVS, FIXED. Please re-open, I get at the moment: >>> checking ebuild checksums ;-) >>> checking auxfile checksums ;-) >>> checking miscfile checksums ;-) >>> checking R-2.3.0.tar.gz ;-) * You need one of these Fortran Compilers: gfortran g77 f2c * Installed are: g77 /usr/portage/dev-lang/R/R-2.3.0.ebuild: line 48: filter-ldflags: command not found >>> Unpacking source... >>> Unpacking R-2.3.0.tar.gz to /var/tmp/portage/R-2.3.0/work revdep-rebuild * Applying patches for selected FORTRAN compiler: g77 >>> Source unpacked. >>> Compiling source in /var/tmp/portage/R-2.3.0/work/R-2.3.0 ... |