Re: [Rd] compiling R under cygwin

From: Latchezar (Lucho) Dimitrov <ldimitro_at_wfubmc.edu>
Date: Thu, 23 Aug 2007 22:10:23 -0400

 

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



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Fri 24 Aug 2007 - 02:29:07 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Fri 24 Aug 2007 - 07:38:58 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.