> -----Original Message----- > From: Duncan Murdoch [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 23, 2007 9:15 PM > To: Latchezar (Lucho) Dimitrov > Cc: Prof Brian Ripley; Denham Robert; r-devel@r-project.org > Subject: Re: [Rd] compiling R under cygwin > > On 23/08/2007 3:33 PM, Latchezar (Lucho) Dimitrov wrote: > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Prof > Brian Ripley > >> Sent: Thursday, August 23, 2007 2:54 AM > >> To: Denham Robert > >> Cc: r-devel@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:[EMAIL PROTECTED] > >>> Sent: Tuesday, 21 August 2007 9:53 PM > >>> To: Duncan Murdoch > >>> Cc: Denham Robert; r-devel@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@r-project.org mailing list > >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>>>> > >>>> ______________________________________________ > >>>> R-devel@r-project.org mailing list > >>>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>>> > >>> > >> -- > >> Brian D. Ripley, [EMAIL PROTECTED] > >> 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@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
