[Rd] compiling R under cygwin
Latchezar (Lucho) Dimitrov
ldimitro at wfubmc.edu
Fri Aug 24 04:10:23 CEST 2007
> -----Original Message-----
> From: Duncan Murdoch [mailto:murdoch at stats.uwo.ca]
> Sent: Thursday, August 23, 2007 9:15 PM
> To: Latchezar (Lucho) Dimitrov
> Cc: Prof Brian Ripley; Denham Robert; r-devel at r-project.org
> Subject: Re: [Rd] compiling R under cygwin
>
> On 23/08/2007 3:33 PM, Latchezar (Lucho) Dimitrov 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.
>
> The issue is compatibility with other Windows programs.
> /path/to/file works in lots of Windows programs, and is
> interpreted relative to the current drive. In the common
> situation where the user only has one partition which is
> mounted as C:, it works (as long as they didn't switch to a
> CD or USB drive).
As I said _if_ you insist on using c (which btw is absolutely not
necessary)
Please see the output of 'ls' and 'dir' bellow:
C:\Documents and Settings\Latchezar M Dimitrov>dir "u:\home\Latchezar M
Dimitrov\cygwin"
Volume in drive U is Users':
Volume Serial Number is 7FC9-20D1
Directory of u:\home\Latchezar M Dimitrov\cygwin
07/30/2007 07:00 PM <DIR> .
07/30/2007 07:00 PM <DIR> ..
07/31/2005 07:39 PM 7,664 .alias
07/29/2005 10:29 AM 7,664 .alias~
07/22/2005 11:24 AM <DIR> .autosave
02/13/2007 04:46 PM 2,791 .bashrc
01/27/2007 08:47 PM 2,631 .bashrc~
08/20/2007 11:55 AM 25,966 .bash_history
01/27/2007 08:48 PM 959 .bash_profile
05/28/2005 06:18 PM 959 .bash_profile~
10/27/2003 09:09 PM 569 .emacs
05/28/2005 06:18 PM 608 .inputrc
11/03/2004 07:17 PM 135 .saves-2440-TheComputer
09/13/2005 01:40 PM <DIR> .semanticdb
07/22/2005 11:24 AM <DIR> .ssh
02/09/2002 11:43 PM 1,003 .Xdefaults
02/22/2006 01:33 AM <DIR> .xemacs
$ls /home/Latchezar\ M\ Dimitrov/cygwin/
total 962
-rwxrwxrwx 1 Latchezar M Dimitrov None 1003 Feb 9 2002 .Xdefaults*
-rwxrwxrwx 1 Latchezar M Dimitrov None 7664 Jul 31 2005 .alias*
-rwxrwxrwx 1 Latchezar M Dimitrov None 7664 Jul 29 2005 .alias~*
drwxrwxrwx+ 2 Latchezar M Dimitrov None 0 Jul 22 2005 .autosave/
-rwxrwxrwx 1 Latchezar M Dimitrov None 25966 Aug 20 11:55
.bash_history*
-rwxrwxrwx 1 Latchezar M Dimitrov None 959 Jan 27 2007
.bash_profile*
-rwxrwxrwx 1 Latchezar M Dimitrov None 959 May 28 2005
.bash_profile~*
-rwxrwxrwx 1 Latchezar M Dimitrov None 2791 Feb 13 2007 .bashrc*
-rwxrwxrwx 1 Latchezar M Dimitrov None 2631 Jan 27 2007 .bashrc~*
-rwxrwxrwx 1 Latchezar M Dimitrov None 569 Oct 27 2003 .emacs*
-rwxrwxrwx 1 Latchezar M Dimitrov None 608 May 28 2005 .inputrc*
-rwxrwxrwx 1 Latchezar M Dimitrov None 135 Nov 3 2004
.saves-2440-TheComputer*
drwxr-xr-x+ 2 Latchezar M Dimitrov None 0 Sep 13 2005
.semanticdb/
drwxrwxrwx+ 2 Latchezar M Dimitrov None 0 Jul 22 2005 .ssh/
drwxrwxrwx+ 2 Latchezar M Dimitrov None 0 Feb 22 2006 .xemacs/
$ls ~
total 962
-rwxrwxrwx 1 Latchezar M Dimitrov None 1003 Feb 9 2002 .Xdefaults*
-rwxrwxrwx 1 Latchezar M Dimitrov None 7664 Jul 31 2005 .alias*
-rwxrwxrwx 1 Latchezar M Dimitrov None 7664 Jul 29 2005 .alias~*
drwxrwxrwx+ 2 Latchezar M Dimitrov None 0 Jul 22 2005 .autosave/
-rwxrwxrwx 1 Latchezar M Dimitrov None 25966 Aug 20 11:55
.bash_history*
-rwxrwxrwx 1 Latchezar M Dimitrov None 959 Jan 27 2007
.bash_profile*
-rwxrwxrwx 1 Latchezar M Dimitrov None 959 May 28 2005
.bash_profile~*
-rwxrwxrwx 1 Latchezar M Dimitrov None 2791 Feb 13 2007 .bashrc*
-rwxrwxrwx 1 Latchezar M Dimitrov None 2631 Jan 27 2007 .bashrc~*
-rwxrwxrwx 1 Latchezar M Dimitrov None 569 Oct 27 2003 .emacs*
-rwxrwxrwx 1 Latchezar M Dimitrov None 608 May 28 2005 .inputrc*
-rwxrwxrwx 1 Latchezar M Dimitrov None 135 Nov 3 2004
.saves-2440-TheComputer*
drwxr-xr-x+ 2 Latchezar M Dimitrov None 0 Sep 13 2005
.semanticdb/
drwxrwxrwx+ 2 Latchezar M Dimitrov None 0 Jul 22 2005 .ssh/
drwxrwxrwx+ 2 Latchezar M Dimitrov None 0 Feb 22 2006 .xemacs/
-rw-r--r-- 1 Latchezar M Dimitrov None 114993 Jul 4 22:21
2NonSelf.txt.columns
drwxrwxrwx+ 2 Latchezar M Dimitrov None 0 Jul 22 2005 Copy of
.xemacs/
drwxrwxrwx+ 3 Latchezar M Dimitrov None 0 Jul 22 2005 LaTeX/
No '/u/'. Convincing? No?
Again, this is not apologetics to cygwin. Just counter-argument. E
pluribus unum as we say (or at least inscribe) here :-)
Latchezar
>
> /c/path/to/file wouldn't work anywhere but in Cygwin or similar.
>
> Duncan Murdoch
>
> >
> > 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