[Rd] compiling R under cygwin
Latchezar (Lucho) Dimitrov
ldimitro at wfubmc.edu
Thu Aug 23 22:42:57 CEST 2007
Depending on what you mean by "native". Anyway, I'd rather have it
uniform to use and easy to maintain across the platforms then keeping
the face of the host os. In any case what I'd suggested is to have the
uniform setup everywhere and "os" specific somewhere in case anybody
needs it. How is that bad? I can tell you it would be a very big issue
to make a "native Windows" user of R to find setwd() on *nix platform.
BTW, R preferred usage is CLI, isn't it. CLI is fully maintained on
Windows too.
Please also note I did not mention cygwin or something and did not
express any attitude to the port/implementation.
Finally I just wanted to have my vote put there (apparently not where
your vote is) not to argue.
> -----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.
> > > >>>
> > > >>> ______________________________________________
> > > >>> 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