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