[Rd] compiling R under cygwin
Prof Brian Ripley
ripley at stats.ox.ac.uk
Thu Aug 23 08:53:31 CEST 2007
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.
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.
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>> ______________________________________________
>> 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
More information about the R-devel
mailing list