compiling R under cygwin

-----Original Message-----
From: Gabor Grothendieck [mailto:ggrothendieck at gmail.com] 
Sent: Thursday, August 23, 2007 4:01 PM
To: Latchezar (Lucho) Dimitrov
Cc: r-devel at r-project.org
Subject: Re: [Rd] compiling R under cygwin

Having it be the same under cygwin as it is for other UNIX 
systems would be ok but for the native Windows port R should 
behave like other Windows applications, not like UNIX applications.

On 8/23/07, Latchezar (Lucho) Dimitrov <ldimitro at wfubmc.edu> wrote:

-----Original Message-----
From: r-devel-bounces at r-project.org
[mailto:r-devel-bounces at r-project.org] On Behalf Of Prof Brian 
Ripley
Sent: Thursday, August 23, 2007 2:54 AM
To: Denham Robert
Cc: r-devel at r-project.org; Duncan Murdoch
Subject: Re: [Rd] compiling R under cygwin

On Thu, 23 Aug 2007, 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.

Some of the reasons we would like a cygwin version aren't

necessarily

good reasons.  We have been using cygwin for sometime,

mostly to deal

with scripting in a combined windows/unix environment.  

We have a 

setup which allows windows users to run many scripts in the

same way

as unix users.  These scripts are often python or shell

scripts.  We

have R installed on the unix machines, and the system

administrators

would like to be able to have R on windows in the same

environment.

This set up also means that the administrator can fairly easily 
maintain the version of software used on all user's machines.
Probably this could all be managed and still use the native 
windows version of R, but the administrator is familiar with 
cygwin

and they

could manage this software in the same way they manage

other packages.

Yes, it could almost certainly be done with Rterm.exe.

The issue I came across was the so-called 'posix file paths'
that Cygwin uses.  Most (but not all) Windows programs 

accept file 

paths with / as the path separator, and most (but not 

all, e.g. tar) 

Cygwin programs accept paths of the forn c:/path/to/file.  So 
provided you use that as your format, interworking with Unix and 
Unix-like shells work fine.  It used to be the case that 

if you had 

just one drive C: then Cygwin programs produced paths of the form 
/path/to/file that also worked on Windows.  Now they produce 
/cygdrive/c/path/to/file that works nowhere else.

I'm not sure what you mean by "produce" above but one can 

easily setup 

(by mount option) cygwin to use "/" instead of "/cygdrive/" so that 
your example above will become "/c/path/to/file". That's if 

you insist 

on using drive letters. Otherwise w/ proper mounting (in 

cygwin) one 

can have "usual" *nix dir tree.

Regards,
Latchezar

PS. I really like the idea of having (the same) bare 

terminal/command 

window interface to R anywhere as well as anything else (like admin 
tasks above) to be the same. So please put my vote (if you care) to 
have R Windows installation look the same as *nix (up to the point 
when you start R from Start button to have terminal version started 
instead of Rgui as it is now) and keep GUI candies separately for 
whoever wants/needs them. Sorry if that's been already done 

and I did 

not know about it.

In general this is a minor nuisance, but I needed to be able to 
cross-build R in an environment where I only have Cygwin-based 
cross-compilers, and there the path issues bit
me: I needed a version of R that accepted and returned 

Cygwin-style 

paths.  So I made the configure changes necessary to 

build R under 

Cygwin, and had it running in 20 mins.

We would like to be able to use linux machines on pc's but 
unfortunately we have restrictions imposed on us that

prevent this.

This restriction also goes as far as the use of virtual

machines.  My

personal preference would be to run linux on my work 

pc, and use a 

virtual machine to run windows software, such as ArcGIS and

Imagine,

that are not available for linux.  This does not seem to be

an option for us.

One thing I was interested in was knowing if there are

others who also

would like a cygwin version.  From the replies to my post,

and from a

search of the mailing list archive, I think that there 

is little 

demand for this.  We would, however, be prepared to help in

some way

for the few people who are interested.

As I said earlier, it builds out of the box in R-devel (with 
suitable options documented in the R-admin manual).  No 

guarantees 

that it will continue to do so unless tested in the 

alpha/beta phase 

though.  As no other platform we use nowadays requires 

that shared 

objects/dynamic libraries have all imports satisfied at 

build time, 

this is liable to get broken.

But I would encourage people to use Rterm.exe if it can 

be made to 

do what you need.

Robert Denham
Environmental Statistician
Remote Sensing Centre
Telephone 07 3896 9899
www.nrw.qld.gov.au

Department of Natural Resources & Water QScape 

Building, 80 Meiers 

Road, Indooroopilly Qld 4068

-----Original Message-----
From: Prof Brian Ripley [mailto:ripley at stats.ox.ac.uk]
Sent: Tuesday, 21 August 2007 9:53 PM
To: Duncan Murdoch
Cc: Denham Robert; r-devel at r-project.org
Subject: Re: [Rd] 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.

(If platforms are not used and in particular not tested in the 
alpha/beta 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.

--
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