compiling R under cygwin

Yes,

What is the advantage of building this?

was my question too.  If you want a Unix-like version of R on PC hardware
running Windows why not run a Unix-like OS under a virtual machine?

Quite a lot of the details are wrong: using FLIBS, BLAS_LIBS and LIBS as
intended will solve most of the problems.  I would use --disable-nls
--disable-mbcs as you don't need them (and in particular you don't benefit
from MBCS support on Windows unless you are in a CJK locale).

Note that 2.5.1 is released and there is unlikely to be a 2.5.2, so any
changes would be made only to R-devel.  It there is a convincing case to
tailor a build for Cygwin there we can probably do so rather easily, but
the need for ongoing support would be a worry.

(I

testing phases then the ability to build on them crumbles away.  We seems
to be down to regular testers on Linux, Windows, MacOS X, Solaris and
FreeBSD, with some help on AIX after a patch with none.)

On Tue, 21 Aug 2007, Duncan Murdoch wrote:

Denham Robert wrote:

For various reasons,

I think it is only courteous to mention some good reasons if you want to
take up people's time.

it suits our workplace to have a cygwin version of
R.  I am pretty sure that cygwin is still not a supported environment
for R, but we have managed to compile R-2.5.1 under cygwin without too
many dramas.  Our procedure is described below.  We still have a few
problems compiling libraries without manually changing files from .so to
.dll, but it seems ok.

I would expect other subtle problems as well, because Cygwin is not a
normal Unix.  I don't know whether any of these differences matter to R,
but some things to look out for are:

- you can't unlink a file while it is open
- filenames are not case sensitive
- file permissions have strange defaults (everything is executable)
- I think the executable format still needs to be Windows format
- There's no such thing as a ptty
- You'll probably need X11 for graphics, and will lose support for
Windows metafile output (wmf)

I was wondering whether this information is likely to be useful to
others, and if we should spend any time looking in to ways in which the
configure/build/install code could be modified to allow a standard
install.

What is the advantage of building this?  I don't think we want to
support platforms just for the sake of supporting more platforms, but if
there's a real need for it, that would be different.

Duncan Murdoch

Notes on building R under cygwin:

export FFLAGS=-O3
export CFLAGS=-O3
export CXXFLAGS=-O3
export OBJCFLAGS=-O3
export FCFLAGS=-O3
export LDFLAGS='-lblas -lg2c -lintl'

export R_OSTYPE=unix

./configure --prefix=/opt/freeware/R/R-2.5.1 \
--with-tcl-config=/usr/lib/tclConfig.sh \
--with-tk-config=/usr/lib/tkConfig.sh \
--with-blas=-lblas \
--with-lapack=-llapack \
--enable-R-shlib

comment out Win32 in src/include/config.h and set Unix to 1, change .so
to .dll. change .so to .dll and in Makeconf.
in src/extra/xdr/rpc/types.h comment out defn of malloc.

Change .so to .dll in Makefile's

edit Makeconf and set R_OSTYPE to unix

make -j2

when blas doesn't link, re-run command with -lblas -lg2c on end and
change output to .dll

edit Rstrptime.c and change wcstod to atof.

in modules:
when X11 and internet falls over add -lintl to link line. add -lg2c and
-lblas to lapack

comment out library/base/R/library.R lines 47-51 to avoid arch check
which seems to go wrong!

make -j2
make install

edit  /opt/freeware/R/R-2.5.1/lib/R/etc/Makeconf and add '-lintl -lg2c
-lblas' to the end of ALL_LIBS
so the module building works. Change .so to .dll also
(can't see how to to this for the build tho...)


Our cygwin info is:
             sysname              release              version
     "CYGWIN_NT-5.1" "1.5.20s(0.155/4/2)"  "20060527 19:21:22"




Robert Denham
Environmental Statistician
Remote Sensing Centre
Telephone 07 3896 9899
www.nrw.qld.gov.au <http://www.nrw.qld.gov.au/>

Department of Natural Resources & Water
QScape Building, 80 Meiers Road, Indooroopilly Qld 4068

************************************************************************
The information in this email together with any attachments is
intended only for the person or entity to which it is addressed
and may contain confidential and/or privileged material.
Any form of review, disclosure, modification, distribution
and/or publication of this email message is prohibited, unless
as a necessary part of Departmental business.
If you have received this message in error, you are asked to
inform the sender as quickly as possible and delete this message
and any copies of this message from your computer and/or your
computer system network.