a plead to package developers regarding GCC
Andy, Are you talking about C or Fortran code here? Fortran has `intrinsics', C does not AFAIK. I think we do pretty strict checking of C code in CRAN packages, and I have not encountered problems with other C compilers (e.g. the Solaris ones). There used to be issues with CRLF line endings, but we check those now. There are a lot of Fortran issues. One is that neither g77 nor gfortran claim to be standards-conformant compilers: g77 is said to compile `GNU Fortran'. Several packages are known not to be Fortran 77 and have been reported to the developers (usually with no response). I tend to use the Solaris compilers to check Fortran, but it is less rigorous than the tests we manage on C code. (And done less systematically, although the R tarball is checked on a wide range of compilers.) There are a dozen or so packages with problems wih 64-bit issues (all of which were reported to the maintainers long ago). We do suggest is that you report specific problems to the relevant package maintainers. They are probably unaware of the issues, and some have been very responsive. If there are some generic issues we can add to the checking process please let us have ideas (offline if you prefer), similar to the CRLF issue mentioned above. Brian
On Tue, 6 Jun 2006, Liaw, Andy wrote:
Dear DevelopeRs, I'd like to ask those who develop R packages with compiled code to please try avoiding dependency on GCC (gcc/g77/gfortran/g++) specific features in the code, for the simple reason that there are non-GCC compilers out there that might choke on such features. I found this out back when I was trying to build R-2.3.0-to-be on our dual Opteron based Scyld cluster. Because the GCC that shipped with the current Scyld is too old for building R properly on that architecture, we ended up using the Portland Group compilers (PGI 6.1). After some update in the R source, I got R to build and pass make check-all. However, when installing contributed packages on CRAN, quite a few failed. I manually checked a handful, and found that some of the code defined some basic math functions that conflicts with intrinsics. Removal of such code enable me to build and run package checks on them successfully. I believe many of such cases stem from the fact that the code were originally from the output of g2c.
f2c?
I can try to post a more concrete example if needed. I think resolving this will facilitate wider use of these packages. Thanks for your consideration. Best, Andy Andy Liaw, PhD Biometrics Research PO Box 2000 RY33-300 Merck Research Labs Rahway, NJ 07065 andy_liaw(a)merck.com 732-594-0820
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595