[Rd] compiling R under cygwin

Gabor Grothendieck ggrothendieck at gmail.com
Thu Aug 23 22:01:02 CEST 2007 

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

More information about the R-devel mailing list