Simon Urbanek wrote: <snipped> > Because it *is* the gcc files? (Note the "/local" in the paths.) Full R > comes with GNU Fortran 4.2.1, because Apple doesn't offer any Fortran > compiler and most other Fortran compiler binaries for Mac OS X out on > the web are not really working well. It installs in /usr/local. <snipped>
This is what I don't understand or agree on. The R windows installer does *not* try to install any of mingw gcc or Rtools. Okay, you cannot install source packages on windows without mingw gcc or Rtools, but that's a caveate. If I were an Apple user (which I am not), there is a chance that I might have my own gcc/gfortran in /usr/local and I surely do not want R to temper with them. If you need runtime libgfortran support, you should just bundle gfortran.so and gcc.so if necesary (there are static alternatives), and put those in R's area. (recently, I took enough trouble of bootstrapping gfortran 4.2.x for cross-compiling - see mingw-devel mailing list archive - because mingw don't distribute that as binary. I have win32 R under wine, but I really would *not* appreciate if win32 R tries to do anything substantially more than just put itself in a directory...). <snipped> > No. The failure is due to a strange symlink in /usr/local/lib that > points to itself. I suspect that this has something to do with an > upgrade from Tiger to Leopard or Xcode 3 installation and that Apple > actually creates that infinite symlink. Given that there is > "/usr/loca/lib 1" lingering around, I'd bet that > > sudo rm /usr/local/lib > sudo mv '/usr/local/lib 1' /usr/local/lib > > will fix the problem. <snipped> Yeah, that apple box is *so* broken.:-). HTL ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
